Open rubinahaddad opened 10 years ago
LXP122
commented
10 years ago CRA-IT will perform a review of this component. As buttons, validations and mandatory field indication is already covered off, the assumption is that the review focus will be on text, textarea, radio button and checkbox control implementation.
rubinahaddad
commented
10 years ago @LXP122 Yes exactly - including all the other form elements (select, multi-select...etc.). This is a big one so thank you for taking it on!
JxRath
commented
10 years ago Short Forms:
http://wet-boew.github.io/v4.0-ci/demos/feedback/feedback-en.html
A. Please indicate which devices were tested (Desktop/Mobile/Tablet): HP Desktop, Dell widescreen monitor (1920x1080), IE Windows 8.0.7601.17514 Apple iPhone 4 – Latest iOS 7 – Mobile Safari iPad mini – Latest iOS 7 – Mobile Safari MacBook Air, Mac OS X V.10.7.5 (Lion), Safari V.6.1.1
B. Provide status feedback
Basic Examples – General comments: Mostly Usable, See specific comments below. For accessibility reasons a study should be done on the contrast of the light grey line around the field to see if the contrast is sufficient.
For the “Email” and “Password” fields, on-hover the arrow cursor changes to a text insertion bar. On-click, the light grey border becomes Cyan and a blinking text insertion line appears indicating that when the user begins to type they will go into the selected field (active status). As the user types, the letters appear as one would expect. When the end of the field is reached the typing can continue as the text scrolls, so the field is actually of “infinite” length. In some applications this would be considered “normal” (e.g. entering long URLs in a limited width browser website address entry field. In other applications where the user would expect a fixed number of characters, this would be considered “wrong” and could lead to data entry errors.
If the user clicks the “Return” or “Enter” key the field becomes blank and the user is taken to the top of the page which was not expected. Clicking the “Tab” key takes the user to the next field or link and clicking “Shift-tab” moves the focus to the previous field or link. Both of these tab behaviours were expected and appropriate.
For most applications a 100% width form field is not appropriate. The length of the field needs to match the number of characters it is supposed to contain; otherwise the user may think they are not entering enough data. (Google - Usability studies on field length) An average email length is from 18 to 35 characters, so allowing for some longer outliers, the field length should not be any more than 50 characters.
A password field should match the site’s standard length for passwords; usually no more than 8 characters, and certainly not 100% page width. This field does use the proper “bullet” character on entering characters to hide the password.
There were no tooltips on any of the “Basic Examples” we should consider whether this should be part of the WET standards. A nice example is http://jquerytools.org/demos/tooltip/form.html As the user clicks in an input field or rolls-over an element, tool-tips appear. Note; the tooltips just referenced could be formatted much better than in the example, but the process is good for tooltips or nuggets of help text.
Basic Example: Email & Password fields – IE 8: Mostly Usable. See comments above. The “Email” and “Password” fields are blank by default. In Safari and iOS 7 the “blank” text fields are not blank. They have greyed input guide text in them “Enter email” and “Password”. This is a better standard. It is possible to do this in IE 8 – see: http://mathiasbynens.be/demo/placeholder
Basic Example: Email & Password Fields – iOS 7, MacBook & Safari: Yes. In Safari and iOS 7 the “blank” text fields are not blank. They have greyed input guide text in them “Enter email” and “Password”. As the user begins to type the grey text disappears and the user entered text appears. This is a much better standard, though the default text needs to use parallel phrase structure (e.g. “Enter email” and “Enter Password” or “Email” and “Password”).
Basic File Input fields – IE 8: No. The default view for the “File input” selector also behaves a bit oddly/differently than Safari and iOS 7. In IE 8 the component shows a greyed input field on the left and a “Browse…” system generated button to the right of the blank field. On roll-over the grey text entry box has a cyan border that appears, showing that it is an “Active” object even though it looks greyed out. When the user clicks on the grey field, a black and white dotted line shows up surrounding both the field and the “Browse…” button. A blinking text insertion cursor also appears, but if the user tries to type nothing happens. A user might want to paste a path to the file in this area and that does not work either. If the user hits the enter key, the “Submit” button below is activated and the user is unexpectedly taken to the top of the screen. If the user double clicks on the form field the result is the same as clicking the “Browse…” button (which was unexpected).
If the user gives up on entering text in the field and rolls-over the “Browse…” button it highlights in cyan showing the button is active and clickable. Oddly, the cursor does not change status to the “Pointing Finger” shape that is the standard for clickable objects like buttons. On-click a Microsoft standard “Choose File to Upload” window appears which would allow the user to select a file for upload/attachment. (This is perhaps a windows UX issue, but the active button reads “Open” instead of a more appropriate “Upload” or “Insert” or “Attach”) On choosing a file in this “Upload” window, if the user clicks “Open” the popup window closes and a path to the file is entered in the still greyed window. Generally the path will be too long to display completely within the box, but if the user “Select-scrolls” they can see the entire path is there. The user can now select everything in the greyed field and delete it if they wish to select another file instead. Also using the “Browse…” button again will allow the user to select a new file and “over-write” the current path/file entered in the input field. Multiple file attachments/uploads do not work with this control. This is somewhat expected as there is only one field associated with the “Browse…” button.
Since the primary control is the “Browse…” button and not the greyed file input field, the button should come before and not after (to the left and not to the right of) the greyed input field. Since the user cannot do anything with the field (type into, or cut and paste into) should it be there at all? The Safari version works better and is less confusing to the user.
Basic File Input fields – MacBook & Safari: No not always. The button uses a “Safari Default” style of button. The button reads “Choose File” with the text “no file selected” to the right of the button. IE used a “Browse…” button so the behavior is not consistent. The function is also activated if the user clicks on the “no file selected” text which was unexpected as the text does not look clickable and the cursor does not change from an arrow to a pointing hand when mousing over the text.
Safari does not display the empty grey field with its associated issues as IE did. The default Apple Button has rounded corners and a gradient so it looks clickable. On-roll-over the button does not highlight (effect broken?) and the arrow cursor does not change to a pointing hand as it should when over buttons or other clickable elements. On-hover a “no file selected” tooltip appears in a yellow floating rectangle. On-click the button becomes cyan and a file selection window slides down from the Safari browser bar. The user selects the file they want to upload/attach and clicks the cyan highlighted “Choose” button. A small file icon with the file name now appears to the right of the “Choose File” button.
Apple uses better button naming choices “Choose File” to initiate the process and “Choose” in the pop-up window to select the correct file and finish the process. IE/Windows uses a “Browse…” and “Open” combination which is not as appropriate. Once the file has been chosen, if the user clicks on the file icon or the file name it acts as if the “Choose File” button was clicked. This was a bit unexpected as there was no cursor status change to a pointing hand when mousing over the file name or file icon.
The mental model is different between IE and Safari. In IE it seems clear that the user is not uploading a file, they are creating a path to the file’s location. If the file was moved from the location it may not work properly. In Safari it seems clear that the user is uploading a file. The user sees the file icon and name, so would likely infer that a copy of the file has been successfully uploaded.
Basic File Input fields – iOS 7: No. While the default “Choose File” button looks clickable, the “no file selected” text next to it is also clickable, but does not communicate its status as such. In iOS 7 there are no roll-over, on-hover or on-click visual effects. On-click, iOS 7 iPad mini uses a “lightbox” type effect, dimming the screen and popping up a selection box with two choices; “Take Photo or Video” or “Choose Existing”. It ignores any other file type other than photos or videos. The iPhone also uses a lightbox effect, but has the third option of “Cancel”. On both devices the user can cancel the process by clicking anywhere on the lightbox background.
“Choose Existing” takes the user to the “Camera Roll” where they can choose only a photo or video. As with IE 8 and Safari, only one file can be chosen, choosing another file will replace the one currently uploaded. Once the photo or video is chosen the user is taken back to the form page and they can see a tiny thumbnail of the photo to the right of the “Choose File” button. To the right of the Thumbnail is the text “1 photo”. If a video is chosen the text will read “1 video”.
“Take Photo or Video” works in a similar fashion but allows the user to take a new photo or video, and not use one currently “in storage” on their device.
For most applications the ability to upload only a photo or video will not be sufficient. Most mobile devices can also contain document (.doc, .pdf) files or have access to them via the cloud (e.g. Dropbox). For mobile use the functionality needs to be extended.
Basic Example: Checkbox – IE 8: No. The cursor changes from an arrow pointer to a finger pointer when mousing over the “check me out” text. This was a bit unexpected as the text does not communicate its status as being “clickable”. There is no visual roll-over or on-hover status change for the text, but on roll-over the associated checkbox becomes highlighted with cyan. On-clicking the text the checkbox becomes selected (checkmark appears) and a black and white dotted line appears around the checkbox. Repeating the action de-selects the checkbox. Similar behavior occurs by clicking the checkbox itself.
Basic Example: Checkbox – MacBook & Safari: No. The cursor change is “Backwards”. On mousing over the “Check me out” text the cursor changes to a pointing hand indicating that the text is clickable even though it doesn’t appear to be. On mousing over the checkbox (which does appear clickable), the cursor does not change to a pointing hand and remains an arrow cursor. Selecting and de-selecting the checkbox works when clicking either the text or the checkbox. Once selected, the checkbox turns cyan, and a black, bold checkmark appears on top of the box.
Basic Example: Checkbox – iOS 7: No. Similar to Safari, the non-clickable looking text is part of the click target to operate the check box. Though unexpected, this actually helps on the mobile devices as it makes the click-target larger. The Checkbox has a different appearance in iOS 7. It has a similar default look t o Safari, but once selected turns black with a white checkmark.
Basic Example: Submit Button – IE 8, iOS 7, MacBook & Safari: No. See full review in the “Buttons” heuristic evaluation.
Inline Form – IE 8: No. The “Inline Form” does not work properly in IE 8. Instead of the elements stacking horizontally in 1 row, they stack vertically in 4 rows (same as “Horizontal Form” below). For other comments about the fields, checkboxes and buttons, see above.
The Button does not look clickable; it’s a word in a box. The “Email” and “Password” fields have no identifiers, as the labels are missing and the grey input guide text that identifies the field in MacBook and iOS, but does not appear in IE8. Light grey edges of the elements may not provide enough contrast on white backgrounds. (Defer to the “Button” standard in the Heuristic Evaluations)
Inline Form – iOS 7, MacBook & Safari: Mostly Yes. The fields, checkbox and Button may not have enough edge contrast on a white background for the visually impaired. Button does not look clickable, but at least in Safari and iOS the corners are a bit rounded to imply a button. For other comments read above. The grey text in the fields identifies them, even without the use of a label.
Horizontal Form – IE 8: Mostly No. See comments above. In IE the horizontal form does not render as intended. It renders with the labels above the fields, instead of a 2 column layout with the labels to the left of the fields in one column and the other 4 elements in rows in another column left-aligned.
Just above the “Supported controls” section there are 4 field examples that did not code/display properly. In IE the 4 fields all display identically with the fields spanning 100% and the labels are above the fields.
Horizontal Form – iOS 7, MacBook & Safari: Mostly Yes. See comments above. Layout is in 2 columns as intended with labels to the left of the fields and greyed text in the fields identifying them.
Just above the “Supported controls” section there are 4 field examples that did not code/display properly. In iOS 7 and Safari, the 2 fields above have the labels above the fields, but they are 25% of the way to the right side of the page. I think they were supposed to render to the left of the fields in one row? The two bottom fields render with the labels above the fields, aligned left.
Supported Controls; Inputs – IE 8: No. The field is missing the grey input guide text in the background which would communicate the field’s type or status.
Supported Controls; Inputs – iOS 7, MacBook & Safari: Mostly Yes. See comments above.
Supported Controls; Text Area – IE 8: Mostly Yes. See comments above. In IE 8 the text wraps in the box when the end of the text area is reached. A scrollbar appears and remains on the right side of the text area when the height of the text block exceeds the height of the text area. If a lot of text is added the “elevator” control in the scrollbar renders improperly losing the top and bottom edges of the control.
Static Controls; Text Area – MacBook & Safari: Mostly Yes. See comments above. In Safari, when the text exceeds the height of the text area a scrollbar appears. The scrollbar then fades from view, and re-appears only when the user tries to scroll. Additionally in Safari, the Text Area Component has two tiny black diagonal lines in the right bottom corner of the text area. There is no roll-over, on-hover, on-click or cursor change when moving the arrow pointer over these lines, but if the user clicks and drags down or to the right the text area will expand. Once the area has been enlarged the text area can be reduced back to its original size (but not smaller) by repeating the process in reverse.
Static Controls; Text Area – iOS 7: Mostly Yes. As with IE and Safari the text area wraps the text properly. When exceeding the height of the text area, the user can continue to type but no scroll bars appear. The user can scroll by touching the text area and dragging up or down, but when hitting the extent of the scroll, the entire window begins to move which can be disconcerting. There is no mechanism to enlarge the text area the way Safari does.
Supported Controls; Checkboxes and Radios – IE 8: No. The text next to the control does not communicate visually its status as being clickable. On roll-over the cursor does change to a pointing hand and the checkbox or radio button associated with it does highlight cyan. This may actually make the task of selecting a radio button or checkbox easier as the “click target” is much larger, so may aid accessibility. Jakob Neilson also recommends making the associated text clickable. On click these elements are surrounded by a black and white dotted line which does not appear in iOS 7 or Safari. The dotted line (if not required for accessibility reasons) can be suppressed with the coding example on the following page: http://www.htmlgoodies.com/beyond/javascript/article.php/3471171/No-Dotted-Line-On-Links.htm
Supported Controls; Checkboxes and Radios – MacBook & Safari: No. The text next to the control does not communicate visually its status as being clickable. On roll-over the cursor changes to the pointing hand on the text, indicating that it is clickable, but the cursor reverts back to the arrow when mousing-over the actual radio button or checkbox.
Supported Controls; Checkboxes and Radios – iOS 7: No. The text next to the control does not communicate visually its status as being clickable. There is no roll-over, cursor change (there is no cursor) or on-click effects. Most of the time, the user will have to pinch zoom in to select the correct target, especially if the options are next to each other vertically.
Supported Controls; Inline Checkboxes – IE 8: No. Read above. Also the alignment of the checkboxes in the row is not great. The numbers should be centered vertically with the checkboxes. At the moment the numbers are too far below the centerline of the checkboxes.
Supported Controls; Inline Checkboxes – MacBook & Safari: No. Read above.
Supported Controls; Inline Checkboxes – iOS 7: No. Read above. Also the tight spacing of the elements makes the touch targets difficult without zooming in.
Supported Controls; Selects – IE 8: No. Different style than the dropdown lists used in the “Lightbox”, “Mandatory Fields” or “Feedback Form”; we should remain consistent within WET. The default option works, but looks like a dropdown control was put inside a text input box, rather than being a true dropdown control. On roll-over the cursor does not change to a pointing hand to indicate that the element is clickable, but the arrow on the right highlights in cyan. On-click a dropdown list appears allowing the user to select a number.
The Second example for multiple select does not work in IE 8 (Bug?). The list is displayed as a text area with 4 options showing, and a scrollbar on the right to scroll down and see the 5th item. Clicking on multiple items in the list does not work. Only one item remains selected at a time.
Supported Controls; Selects – MacBook & Safari: No. It is a different style than the dropdown lists used in the “Lightbox”, “Mandatory Fields” or “Feedback Form”; we should remain consistent within WET. The first example does use a nice gradient and looks clickable. On roll-over there is no cursor change to a pointing hand to indicate that the element is clickable.
The Second example does not work in Safari or Chrome (Bug?). As in IE 8, the list is displayed as a text area with 4 options showing, but in Safari there is no scrollbar on the right to scroll down and see the 5th item. Clicking on multiple items in the list does not work. Only one item remains selected at a time.
Supported Controls; Selects – iOS iPad mini: No; it has some issues. Both examples look like a dropdown list. The first example uses a downward pointing arrow to indicate that it is a dropdown list. The Second example uses a “…” to try to indicate that multiple items can be chosen from the list.
On-click both examples use a lightbox effect. The background of the page is greyed out and a white box with a pointer to control being used appears. In the first example as the user makes a selection the number immediately updates and then the control disappears. The text on the grey dropdown bar changes to reflect the user selection made.
In the second example the default text on the grey bar is “0 Items”. On-click it uses the lightbox effect described above. A list appears with 5 items. If the third item is chosen it updates the text on the grey bar to “3” when it should be “1 item”. If 2 items are chosen then it properly updates to “2 items” or however many items were chosen. It is just the single selection of items that is “broken”.
Supported Controls; Selects – iOS iPhone: No; it has some issues. The iPhone uses the “Rolodex” control to allow the user to make a selection. In the first example it works as expected.
In the second example it does not work properly for multiple selections. Making one selection does not work; it remains at “0 items”. Selecting 2 items does not work; the text changes to “1” instead of “2 items”. The code for this multiple selection component had issues in all 4 devices/systems so will need further work and de-bugging.
Supported Controls; Static Control – IE 8: No. The controls are supposed to format with the labels to the left and the elements (email@example.com & password form field) to the right. IE ignores the desired formatting and places the elements underneath the labels. Also the grey text to identify the password field is missing.
Supported Controls; Static Control – iOS 7, MacBook & Safari: Yes. Status of field and layout works and looks as expected.
Form States; Input Focus – IE 8, iOS 7, MacBook & Safari: No. The field does not appear to have a “focussed” state. Looks like a regular field with some text in it.
Form States; Disabled Inputs – IE 8: No. It does not communicate fully as a disabled field. The field is greyed out, but the text “Disabled input here” which appears in Safari does not appear in IE. Also as part of the disabled state there should be a cursor change to the red circle with a diagonal line through it as is used elsewhere in the WET standard. In this example there is no cursor change on roll-over.
Form States; Disabled Inputs – iOS 7, MacBook & Safari: Yes. Looks and works as a disabled field. Greyed text appears in the greyed field. In Safari on MacBook the cursor also changes to a white circle with a diagonal line through it on mouse-over.
Form States; Disabled Fieldsets – IE 8: No. None of the 4 examples shown communicates its status properly.
No. The “Disabled Input” label and field looks greyed out, on-roll-over there is no change, but on-click a blinking text insertion bar appears and the user can enter text in the field so it is not really disabled.
No. The “Disabled select menu” label is grey, but the dropdown itself has black text on it and does not particularly look disabled. On roll-over there is no cursor change, and on-click nothing happens so it at least acts disabled, even though it does not particularly look disabled.
No. The “Checkbox” example half works. The “Can’t check this” text looks greyed out. If the user could see an active checkbox next to the inactive one, they would notice the difference. In isolation, because WET is using a light grey border for so many elements, it is not likely they would guess the checkbox is disabled. On-rollover on the greyed “Can’t check this” text, the cursor changes to the pointing hand indicating that it can be clicked… but it really can’t. The cursor changes correctly over the checkbox element itself, displaying the red circle with a diagonal line through it.
No. The “Submit” button uses a grey text with a white drop-shadow. This is an odd colour choice for a dropshadow; generally one would use a darker tone. This looks like a reverse highlight. The white dropshadow also makes the “m” look like a “rn” because the white has more visible contrast than the light grey. Also the disabled button is “broken” because it works. On roll-over of the button body, the cursor does not change from the white arrow. On roll-over of the text the cursor changes to a text insertion bar. On-click, the button works and links to the top of the page.
For all of the disabled fieldsets and controls WET should consistently change the cursor to the red circle with the line through it.
Form States; Disabled Fieldsets – iOS, MacBook & Safari: Yes and No. iOS looks and works the same as Safari in these examples, except iOS does not use cursors.
Yes. The “Disabled Input” label remains bold and black; it is not greyed out as in IE. The disabled field itself looks greyed, with greyed text reading “Disabled Input”. On roll-over the cursor changes to the white circle with a line though it, so it does communicate its status as being disabled.
No. The “Disabled select menu” label is black and bold, and the dropdown itself has black text and black up/down arrows on it and does not particularly look disabled. On roll-over the cursor does change to the white circle with a line though it, so only on roll-over does it communicate its status as being disabled.
No. The “Checkbox” example does not particularly look disabled in isolation. The checkbox is distinct enough, and retains its gradient so it looks clickable. On roll-over the cursor does change to the white circle with a line though it, so only on roll-over does it communicate its status as being disabled. The associated “Can’t check this” text does not look greyed, it is regular black text. On roll-over the cursor changes to the pointing hand, indicating that it can be clicked (but it can’t).
No. The “Submit” button does not look disabled. The mid blue colour of the button with white text could be interpreted as a style choice. The odd dropshadow effect that IE displays is not shown in Safari. On roll-over there is no cursor change to indicate that the button is disabled. Unlike IE, on-click the button does not work. The lack of functionality on-click may be the only indication that the button is disabled, but the user may just interpret it as being “broken”.
For all of the disabled fieldsets and controls WET should consistently change the cursor in Safari to the white circle with the line through it. It would be a bonus if it matched the red circle that IE uses.
Form States; Validation States – IE, iOS 7, MacBook & Safari: No. The visual status using colour is not sufficient. There is not enough visual feedback to indicate success or failure. In IE the 1px line color change will not be enough to be noticed. The addition of the label colour change helps, but will not be sufficient for the 20% of the population that has some form of colour blindness. For a much better implementation, see: http://alittlecode.com/files/jQuery-Validate-Demo/index.html This is a much better example and is also based on Bootstrap.
Control Sizing; Height sizing – IE 8, iOS 7, MacBook & Safari: Yes. The height sizing works as expected.
Control Sizing; Column sizing – IE 8, iOS 7, MacBook & Safari: Yes. The column sizing works as expected.
Help Text – IE 8, iOS 7, MacBook & Safari: Almost. The help text under the field is a dark grey that is close to the black text above. The only concern is that due to the spacing between the elements it may not be obvious that the grey text is associated with the field; but it might be clearer in context. It does not necessarily communicate its status as “Help text”
Input Groups; Basic Example – IE 8, iOS 7, MacBook & Safari: Mostly Yes. Depending on the context and what the user sees in the attached area, people may assume that the item attached to the field is a button. This might be a common mistake due to WET’s current flat button style choice.
Input Groups; Sizing – IE 8, iOS 7, MacBook & Safari: Yes. Works and looks as expected.
Input Groups; Checkboxes and Radio Addons – IE 8, iOS 7, MacBook & Safari: No. Looks as expected, but on mouse-over of the radio button or checkbox there is no associated cursor status change to the pointing hand as there should be. Also once triggered, the radio button would not become un-selected; but that is likely due to the fact that radio buttons always should come in sets of at least 2.
Input Groups; Button Addons – IE 8, iOS 7, MacBook & Safari: Yes; for the addon. No; for the buttons. The buttons do not look like buttons until the user mouses-over them.
Input Groups; Button with dropdowns – IE 8, iOS 7, MacBook & Safari: Yes; for the addon. No; for the dropdown buttons. The downward pointing arrow status implies that a dropdown list will appear, but it does not. Perhaps it wasn’t coded into the example, or it might be broken.
Input Groups; Segmented Buttons – IE 8, iOS 7, MacBook & Safari: Yes; for the addon. No; for the dropdown segmented buttons. The downward pointing arrow status implies that a dropdown list will appear, but it does not. Perhaps it wasn’t coded into the example, or it might be broken.
Basic Example: Email & Password fields – IE 8: Mostly Usable. Missing grey “prompt” text in fields that appears in iOS and Safari.
Basic Example: Email & Password Fields – iOS 7, MacBook & Safari: Yes. Feedback is good. Password field uses correct “bullet” text.
Basic File Input fields – IE 8: No. Feedback is inappropriate in the greyed field. See comments above.
Basic File Input fields – MacBook & Safari: Yes works as expected for single file attachment. Does not work for multiple file uploads.
Basic File Input fields – iOS 7: No. Feedback produces an unexpected result. “Choose file” will only upload photos or videos; no other file type is supported.
Basic Example: Checkbox – IE 8: No. There is a lack of proper feedback to show the text is clickable.
Basic Example: Checkbox – MacBook & Safari: No. There is a lack of proper cursor change over the checkbox.
Basic Example: Checkbox – iOS 7: No. Text is clickable but does not provide the proper feedback.
Basic Example: Submit Button – IE 8, iOS 7, MacBook & Safari: No. See full review in the “Buttons” heuristic evaluation.
Inline Form – IE 8: No. The “Inline Form” does not format properly in IE 8.
Inline Form – iOS 7, MacBook & Safari: Mostly Yes. Though as mentioned above the cursor change on mousing over the checkbox does not provide the proper feedback.
Horizontal Form – IE 8: No. See comments above. Hitting Return key causes the field to go blank and links to top of page.
Horizontal Form – iOS 7, MacBook & Safari: No. See comments above. Hitting Return key causes the field to go blank and links to top of page.
Supported Controls; Inputs – IE 8: No; missing grey prompt text in field. Hitting Return key causes the field to go blank and links to top of page.
Supported Controls; Inputs – iOS 7, MacBook & Safari: No; Hitting Return key causes the field to go blank and links to top of page.
Supported Controls; Text Area – IE 8: Mostly Yes. Feedback is appropriate. Return key works as expected, scrollbars appear and disappear as required.
Static Controls; Text Area – MacBook & Safari: Mostly Yes. Cursor change when resizing the text area does not use the appropriate feedback. Safari uses disappearing scroll bar which is their OS standard.
Static Controls; Text Area – iOS 7: Mostly Yes. Feedback for scrolling is a bit “touchy”. No scroll bars appear.
Supported Controls; Checkboxes and Radios – IE 8: Mostly yes. Checkboxes and radio buttons and cursor change work as expected. Text is clickable but does not provide the proper on-click feedback.
Supported Controls; Checkboxes and Radios – MacBook & Safari: No. Feedback is not appropriate. The cursor needs to change to a pointing hand over the radio buttons and checkbox. Text is clickable but does not provide the proper on-click feedback.
Supported Controls; Checkboxes and Radios – iOS 7: Mostly yes. Text is clickable but does not provide the proper on-click feedback.
Supported Controls; Inline Checkboxes – IE 8: Mostly yes. Appropriate feedback and cursor change. Text is clickable but does not provide the proper on-click feedback.
Supported Controls; Inline Checkboxes – MacBook & Safari: No. The cursor does not change over the clickable checkboxes. Text is clickable but does not provide the proper on-click feedback.
Supported Controls; Inline Checkboxes – iOS 7: Mostly yes. Text is clickable but does not provide the proper on-click feedback.
Supported Controls; Selects – IE 8, iOS 7, MacBook & Safari: No. The multiple select component is broken. See comments above.
Supported Controls; Static Control – IE 8: Component layout is broken in IE, but the feedback is appropriate except for lack of grey prompt text.
Supported Controls; Static Control – iOS 7, MacBook & Safari: Yes. Feedback is appropriate and works as expected.
Form States; Input Focus – IE 8, iOS 7, MacBook & Safari: No. Feedback for input focus is lacking. On-click does activate the focussed state, but I think this example was supposed to show the focussed state without the on-click?
Form States; Disabled Inputs – IE 8: No. There is a lack of cursor change on roll-over to the red circle with a line through it that would provide the proper feedback.
Form States; Disabled Inputs – iOS 7, MacBook & Safari: Yes. Feedback is appropriate, as is the cursor change on roll-over in Safari.
Form States; Disabled Fieldsets – IE 8: No. Feedback is inappropriate. Read the comments above.
Form States; Disabled Fieldsets – iOS, MacBook & Safari: No. Feedback is inappropriate. Read the comments above.
Form States; Validation States – IE, iOS 7, MacBook & Safari: No. There is not enough visual feedback to indicate success or failure. In IE the 1px line color will not be enough to be noticed. The addition of the label colour change helps, but will not be sufficient for the 20% of the population that has some form of colour blindness. For a much better implementation and feedback, See: http://alittlecode.com/files/jQuery-Validate-Demo/index.html This is a much better example and is also based on Bootstrap.
Control Sizing; Height sizing – IE 8, iOS 7, MacBook & Safari: Yes. Feedback is appropriate.
Control Sizing; Column sizing – IE 8, iOS 7, MacBook & Safari: Mostly Yes. Feedback is appropriate, but IE 8 is missing the grey prompt text.
Help Text – IE 8, iOS 7, MacBook & Safari: N/A
Input Groups; Basic Example – IE 8, iOS 7, MacBook & Safari: Yes. Though due to the WET flat button style, users might expect the attached labels to work as buttons.
Input Groups; Sizing – IE 8, iOS 7, MacBook & Safari: Yes. Though due to the WET flat button style, users might expect the attached labels to work as buttons.
Input Groups; Checkboxes and Radio Addons – IE 8, iOS 7, MacBook & Safari: No. Feedback does not provide the appropriate cursor change when rolling-over the controls.
Input Groups; Button Addons – IE 8, iOS 7, MacBook & Safari: No. Buttons do not look like buttons, but there is the appropriate feedback for roll-over effect, cursor change and on-click effects for IE and Safari.
Input Groups; Button with dropdowns – IE 8, iOS 7, MacBook & Safari: No. Buttons do not look like buttons, but there is the appropriate feedback for roll-over effect, cursor change and on-click effects for IE and Safari. Nothing happens when the button is clicked; the proper feedback would be the opening of a dropdown menu.
Input Groups; Segmented Buttons – IE 8, iOS 7, MacBook & Safari: No. Buttons do not look like buttons, but there is the appropriate feedback for roll-over effect, cursor change and on-click effects for IE and Safari. Nothing happens when the button is clicked; the proper feedback would be the opening of a dropdown menu.
Basic Example: Email & Password fields – IE 8: Yes.
Basic Example: Email & Password Fields – iOS 7, MacBook & Safari: Yes.
Basic File Input fields – IE 8: No. Feedback is inappropriate for the visual cues provided by the greyed field. See comments above.
Basic File Input fields – MacBook & Safari: Yes. Works as expected for single file attachment. Does not work for multiple file uploads.
Basic File Input fields – iOS 7: No. “Choose file” will only upload photos or videos.
Basic Example: Checkbox – IE 8: No. There are no visual cues to show the text is clickable.
Basic Example: Checkbox – MacBook & Safari: No. There is a lack of proper visual cues; the cursor does not change when mousing-over the checkbox.
Basic Example: Checkbox – iOS 7: No. Text is clickable but does not provide the proper visual cues.
Basic Example: Submit Button – IE 8, iOS 7, MacBook & Safari: No. See full review in the “Buttons” heuristic evaluation.
Inline Form – IE 8: No. The “Inline Form” does not format properly in IE 8. There is also the lack of visual cues as to what the fields are for due to lack of labels and lack of grey prompt text in the fields.
Inline Form – iOS 7, MacBook & Safari: Mostly Yes. The grey prompt text in the fields identifies them even with the filed labels missing. Though as mentioned above the lack of cursor change on mousing over the checkbox does not provide the proper visual cues.
Horizontal Form – IE 8: No. See comments above.
Horizontal Form – iOS 7, MacBook & Safari: No. See comments above.
Supported Controls; Inputs – IE 8: No; missing grey prompt text in field and label above field.
Supported Controls; Inputs – iOS 7, MacBook & Safari: Yes. Even with lack of label, the grey prompt text will aid the user in entering the correct information.
Supported Controls; Text Area – IE 8: Mostly Yes. Visual cues are appropriate. Return key works as expected, scrollbars appear and disappear as required.
Static Controls; Text Area – MacBook & Safari: Mostly Yes. The visual cue of a cursor change when resizing the text area does not occur. Safari uses disappearing scroll bar which is a new OS standard.
Static Controls; Text Area – iOS 7: Mostly Yes. There is no visual cue of scroll bars appearing when the size of the text exceeds the size of the input box.
Supported Controls; Checkboxes and Radios – IE 8: Mostly yes. Checkboxes and radio buttons and cursor change work as expected. Text is clickable but does not provide the proper visual cue of on-click feedback.
Supported Controls; Checkboxes and Radios – MacBook & Safari: No. Feedback is not appropriate. The cursor needs to change to a pointing hand over the radio buttons and checkbox. Text is clickable but does not provide the proper visual cue of on-click feedback.
Supported Controls; Checkboxes and Radios – iOS 7: Mostly yes. Text is clickable but does not provide the proper visual cue of on-click feedback.
Supported Controls; Inline Checkboxes – IE 8: Mostly yes. Appropriate feedback and cursor change. Text is clickable but does not provide the proper visual cue of on-click feedback.
Supported Controls; Inline Checkboxes – MacBook & Safari: No. The cursor does not change over the clickable checkboxes. Text is clickable but does not provide the proper visual cue of on-click feedback.
Supported Controls; Inline Checkboxes – iOS 7: Mostly yes. Text is clickable but does not provide the proper visual cue of on-click feedback.
Supported Controls; Selects – IE 8, iOS 7, MacBook & Safari: No. Multiple select component is broken. See comments above.
Supported Controls; Static Control – IE 8: Component layout is broken in IE, feedback is appropriate except for lack of visual cue of grey prompt text.
Supported Controls; Static Control – iOS 7, MacBook & Safari: Yes. Feedback is appropriate and works as expected.
Form States; Input Focus – IE 8, iOS 7, MacBook & Safari: No. Visual cue for input focus is lacking. On-click does activate the focussed state, but I think this example was supposed to show the focussed state without the on-click?
Form States; Disabled Inputs – IE 8: No. There is a lack of the visual cue of the cursor change on roll-over to the red circle with a line through it.
Form States; Disabled Inputs – iOS 7, MacBook & Safari: Yes. Feedback is appropriate as is the visual cue of the cursor change on roll-over in Safari.
Form States; Disabled Fieldsets – IE 8: No. Visual cues are inappropriate. Disabled input field is not actually disabled. Read the comments above.
Form States; Disabled Fieldsets – iOS, MacBook & Safari: No. Visual cues are inappropriate. Read the comments above.
Form States; Validation States – IE, iOS 7, MacBook & Safari: No. There are not enough visual cues to indicate success or failure. In IE the 1px line color will not be enough to be noticed (dark green line looks black. The addition of the label colour change helps, but will not be sufficient for the 20% of the population that has some form of colour blindness. For a much better implementation and visual cues, See: http://alittlecode.com/files/jQuery-Validate-Demo/index.html This is a much better example and is also based on Bootstrap.
Control Sizing; Height sizing – IE 8, iOS 7, MacBook & Safari: Yes. Visual cues are appropriate.
Control Sizing; Column sizing – IE 8, iOS 7, MacBook & Safari: Mostly Yes. Feedback is appropriate, but IE 8 is missing the visual cues of the grey prompt text.
Help Text – IE 8, iOS 7, MacBook & Safari: Mostly Yes. The grey help text below the field may need to be better visually associated with the field above.
Input Groups; Basic Example – IE 8, iOS 7, MacBook & Safari: Yes. Though due to the flat button style that WET is using, some might expect the attached labels to work as buttons.
Input Groups; Sizing – IE 8, iOS 7, MacBook & Safari: Yes. Though due to the flat button style that WET is using, some might expect the attached labels to work as buttons.
Input Groups; Checkboxes and Radio Addons – IE 8, iOS 7, MacBook & Safari: No. There is not the appropriate visual cue of the correct cursor change when rolling-over the controls.
Input Groups; Button Addons – IE 8, iOS 7, MacBook & Safari: No. The “Go!” buttons do not look like buttons, but there is the appropriate visual cues of roll-over effect, cursor change and on-click effects for IE and Safari.
Input Groups; Button with dropdowns – IE 8, iOS 7, MacBook & Safari: No. Buttons do not look like buttons, but there is the appropriate visual cues of roll-over effect, cursor change and on-click effects for IE and Safari. Nothing happens when the button is clicked when the proper feedback would be the opening of a dropdown menu.
Input Groups; Segmented Buttons – IE 8, iOS 7, MacBook & Safari: No. Buttons do not look like buttons, but there is the appropriate visual cues of roll-over effect, cursor change and on-click effects for IE and Safari. Nothing happens when the button is clicked when the proper feedback would be the opening of a dropdown menu.
Basic Example; Email & Password fields – IE 8, iOS 7, MacBook & Safari: N/A
Basic Example; File Input fields – IE 8: Yes. There is a “Browse…” button that brings a popup window into view.
Basic Example; File Input fields – iOS 7, MacBook & Safari: Yes. There is a “Choose File” button that brings a popup window into view.
Basic Example; Checkbox – IE 8: Yes, clicking on the empty checkbox causes the checkmark to appear.
Basic Example; Checkbox – iOS 7, MacBook & Safari: Yes, clicking on the empty checkbox causes the checkmark to appear.
Basic Example; Submit Button – IE 8, iOS 7, MacBook & Safari: N/A
Inline Form – IE 8: Inline Form – iOS 7, MacBook & Safari: N/A
Horizontal Form – IE 8, iOS 7, MacBook & Safari: N/A
Supported Controls; Inputs – IE 8, iOS 7, MacBook & Safari: N/A
Supported Controls; Text Area – IE 8, iOS 7, MacBook & Safari: N/A
Supported Controls; Checkboxes and Radios – IE 8, iOS 7, MacBook & Safari: Clicking on the “empty” control changes it to the active state.
Supported Controls; Inline Checkboxes – IE 8, iOS 7, MacBook & Safari: Clicking on the “empty” control changes it to the active state.
Supported Controls; Selects – IE 8, iOS 7, MacBook & Safari: The Multiple Select component is broken; the Single Select has a dropdown list that appears when the user clicks on the control.
Supported Controls; Static Control – IE 8, iOS 7, MacBook & Safari: N/A
Form States; Input Focus – IE 8, iOS 7, MacBook & Safari: N/A
Form States; Disabled Inputs – IE 8, iOS 7, MacBook & Safari: N/A
Form States; Disabled Fieldsets – IE 8, iOS 7, MacBook & Safari: N/A
Form States; Validation States – IE, iOS 7, MacBook & Safari: N/A
Control Sizing; Height sizing – IE 8, iOS 7, MacBook & Safari: 3 of the elements are dropdown lists. Clicking on them causes the list to appear.
Control Sizing; Column sizing – IE 8, iOS 7, MacBook & Safari: N/A
Help Text – IE 8, iOS 7, MacBook & Safari: N/A
Input Groups; Basic Example – IE 8, iOS 7, MacBook & Safari: N/A
Input Groups; Sizing – IE 8, iOS 7, MacBook & Safari: N/A
Input Groups; Checkboxes and Radio Addons – IE 8, iOS 7, MacBook & Safari: N/A
Input Groups; Button Addons – IE 8, iOS 7, MacBook & Safari: N/A
Input Groups; Button with dropdowns – IE 8, iOS 7, MacBook & Safari: Clicking on the button with the dropdown arrow is supposed to cause a dropdown list to appear, but it does not.
Input Groups; Segmented Buttons – IE 8, iOS 7, MacBook & Safari: Clicking on the button with the dropdown arrow is supposed to cause a dropdown list to appear, but it does not.
C. Match real world conventions
Basic Example: Email & Password fields – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above.
Basic File Input fields – IE 8: Mostly No. See comments above. It looks like it’s referencing a path rather that attaching/uploading a file.
Basic File Input fields – MacBook & Safari: Yes.
Basic File Input fields – iOS 7: No. Only allows upload/attachment of Photo and Video files.
Basic Example: Checkbox – IE 8, iOS7, MacBook & Safari: Mostly Yes.
Basic Example: Submit Button – IE 8, iOS 7, MacBook & Safari: No. does not look like a button.
Inline Form – IE 8: No. The layout does not format properly.
Inline Form - iOS 7, MacBook & Safari: Mostly yes. See comments above.
Horizontal Form – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above.
Supported Controls; Inputs – IE 8: No. There is no field label or grey prompt text.
Supported Controls; Inputs – iOS 7, MacBook & Safari: Yes. There is no field label, but there is grey prompt text to identify the field.
Supported Controls; Text Area – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above.
Supported Controls; Checkboxes and Radios – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above.
Supported Controls; Inline Checkboxes – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above.
Supported Controls; Selects – IE 8, iOS 7, MacBook & Safari: Mostly yes for the single dropdown. No for the multiple select dropdown; component is broken.
Supported Controls; Static Control – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above.
Form States; Input Focus – IE 8, iOS 7, MacBook & Safari: No. See comments above.
Form States; Disabled Inputs – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above.
Form States; Disabled Fieldsets – IE 8: No. See comments above.
Form States; Disabled Fieldsets – iOS, MacBook & Safari: Mostly yes. See comments above.
Form States; Validation States – IE, iOS 7, MacBook & Safari: No. See comments above.
Control Sizing; Height sizing – IE 8, iOS 7, MacBook & Safari: Yes. See comments above.
Control Sizing; Column sizing – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above.
Help Text – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above.
Input Groups; Basic Example – IE 8, iOS 7, MacBook & Safari: Mostly no. See comments above.
Input Groups; Sizing – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above.
Input Groups; Checkboxes and Radio Addons – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above.
Input Groups; Button Addons – IE 8, iOS 7, MacBook & Safari: No. See comments above.
Input Groups; Button with dropdowns – IE 8, iOS 7, MacBook & Safari: No. See comments above.
Input Groups; Segmented Buttons – IE 8, iOS 7, MacBook & Safari: No. See comments above.
Basic Example: Email & Password fields – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above.
Basic File Input fields – IE 8: Mostly No. See comments above. It looks like it’s referencing a path rather that attaching/uploading a file.
Basic File Input fields – MacBook & Safari: Yes.
Basic File Input fields – iOS 7: No. Only allows upload/attachment of Photo and Video files.
Basic Example: Checkbox – IE 8, iOS7, MacBook & Safari: Mostly Yes.
Basic Example: Submit Button – IE 8, iOS 7, MacBook & Safari: No. does not look like a button.
Inline Form – IE 8: No. The layout does not format properly.
Inline Form - iOS 7, MacBook & Safari: Mostly yes. See comments above.
Horizontal Form – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above.
Supported Controls; Inputs – IE 8: No. There is no field label or grey prompt text.
Supported Controls; Inputs – iOS 7, MacBook & Safari: Yes. There is no field label, but there is grey prompt text to identify the field.
Supported Controls; Text Area – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above.
Supported Controls; Checkboxes and Radios – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above.
Supported Controls; Inline Checkboxes – IE 8, iOS 7, MacBook & Safari: Mostly yes. Some layout issues in IE. See comments above.
Supported Controls; Selects – IE 8, iOS 7, MacBook & Safari: Mostly yes for the single dropdown. No for the multiple select dropdown; component is broken.
Supported Controls; Static Control – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above.
Form States; Input Focus – IE 8, iOS 7, MacBook & Safari: No. See comments above.
Form States; Disabled Inputs – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above.
Form States; Disabled Fieldsets – IE 8: No. See comments above.
Form States; Disabled Fieldsets – iOS, MacBook & Safari: Mostly yes. Cursor change issues. See comments above.
Form States; Validation States – IE, iOS 7, MacBook & Safari: No. See comments above.
Control Sizing; Height sizing – IE 8, iOS 7, MacBook & Safari: Yes. See comments above.
Control Sizing; Column sizing – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above.
Help Text – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above.
Input Groups; Basic Example – IE 8, iOS 7, MacBook & Safari: Mostly no. See comments above.
Input Groups; Sizing – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above.
Input Groups; Checkboxes and Radio Addons – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above.
Input Groups; Button Addons – IE 8, iOS 7, MacBook & Safari: No. See comments above.
Input Groups; Button with dropdowns – IE 8, iOS 7, MacBook & Safari: No. See comments above.
Input Groups; Segmented Buttons – IE 8, iOS 7, MacBook & Safari: No. See comments above.
D. Apply standards and ensure consistency
Basic Example: Email & Password fields – IE 8, iOS 7, MacBook & Safari: No. See comments above. Grey prompt text in blank fields is not consistent between IE and Safari/iOS 7. Some issues with the proper and consistent use of cursor change on roll-over.
Basic File Input fields – IE 8: Mostly No. See comments above. There is a lack of consistency between IE and Safari and iOS 7. IE looks like it’s referencing a path rather that attaching/uploading a file. Safari looks as if it is uploading a file, iOS 7 will only upload photos or videos.
Basic Example: Checkbox – IE 8, iOS7, MacBook & Safari: Mostly Yes. See comments above. Some issues with the proper and consistent use of cursor change on roll-over.
Basic Example: Submit Button – IE 8, iOS 7, MacBook & Safari: Yes. Though there is a general lack of roll-over and on-click behavior in iOS 7.
Inline Form – IE 8: No. The layout does not format properly.
Inline Form - iOS 7, MacBook & Safari: Yes. See comments above.
Horizontal Form – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above.
Supported Controls; Inputs – IE 8, iOS 7, MacBook & Safari: No. There is no grey prompt text in IE. iOS 7 and Safari use grey prompt text to identify the field.
Supported Controls; Text Area – IE 8, iOS 7, MacBook & Safari: There is an inconsistent use of scrollbars between IE, iOS 7 and Safari. See comments above.
Supported Controls; Checkboxes and Radios – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above. Some issues with the proper and consistent use of cursor change on roll-over.
Supported Controls; Inline Checkboxes – IE 8, iOS 7, MacBook & Safari: Mostly yes. Some layout issues in IE. See comments above. Some issues with the proper and consistent use of cursor change on roll-over.
Supported Controls; Selects – IE 8, iOS 7, MacBook & Safari: Mostly yes for the single dropdown. No for the multiple select dropdown; component is broken.
Supported Controls; Static Control – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above.
Form States; Input Focus – IE 8, iOS 7, MacBook & Safari: No. See comments above.
Form States; Disabled Inputs – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above.
Form States; Disabled Fieldsets – IE 8: No. See comments above.
Form States; Disabled Fieldsets – iOS, MacBook & Safari: Mostly yes. Cursor change issues. See comments above.
Form States; Validation States – IE, iOS 7, MacBook & Safari: Yes. See comments above.
Control Sizing; Height sizing – IE 8, iOS 7, MacBook & Safari: Yes. See comments above.
Control Sizing; Column sizing – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above.
Help Text – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above.
Input Groups; Basic Example – IE 8, iOS 7, MacBook & Safari: Mostly no. See comments above.
Input Groups; Sizing – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above.
Input Groups; Checkboxes and Radio Addons – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above.
Input Groups; Button Addons – IE 8, iOS 7, MacBook & Safari: No. See comments above.
Input Groups; Button with dropdowns – IE 8, iOS 7, MacBook & Safari: No. See comments above.
Input Groups; Segmented Buttons – IE 8, iOS 7, MacBook & Safari: No. See comments above.
Basic Example: Email & Password fields – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above. Grey prompt text in blank fields is not consistent between IE and Safari/iOS 7. Some issues with the proper and consistent use of cursor change on roll-over.
Basic File Input fields – IE 8: Mostly No. See comments above. There is a lack of consistency between IE and Safari and iOS 7. IE looks like it’s referencing a path rather that attaching/uploading a file. Safari looks as if it is uploading a file, iOS 7 will only upload photos or videos.
Basic Example: Checkbox – IE 8, iOS7, MacBook & Safari: Mostly Yes. See comments above. Some issues with the proper and consistent use of cursor change on roll-over.
Basic Example: Submit Button – IE 8, iOS 7, MacBook & Safari: Yes. Though there is a general lack of roll-over and on-click behavior in iOS 7.
Inline Form – IE 8: No. The layout does not format properly.
Inline Form - iOS 7, MacBook & Safari: Yes. See comments above.
Horizontal Form – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above.
Supported Controls; Inputs – IE 8, iOS 7, MacBook & Safari: No. There is no grey prompt text in IE. iOS 7 and Safari use grey prompt text to identify the field.
Supported Controls; Text Area – IE 8, iOS 7, MacBook & Safari: There is an inconsistent use of scrollbars between IE, iOS 7 and Safari. See comments above.
Supported Controls; Checkboxes and Radios – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above. Some issues with the proper and consistent use of cursor change on roll-over.
Supported Controls; Inline Checkboxes – IE 8, iOS 7, MacBook & Safari: Mostly yes. Some layout issues in IE. See comments above. Some issues with the proper and consistent use of cursor change on roll-over.
Supported Controls; Selects – IE 8, iOS 7, MacBook & Safari: Mostly yes for the single dropdown. No for the multiple select dropdown; component is broken.
Supported Controls; Static Control – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above.
Form States; Input Focus – IE 8, iOS 7, MacBook & Safari: No. See comments above.
Form States; Disabled Inputs – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above.
Form States; Disabled Fieldsets – IE 8: No. See comments above.
Form States; Disabled Fieldsets – iOS, MacBook & Safari: Mostly yes. Cursor change issues. See comments above.
Form States; Validation States – IE, iOS 7, MacBook & Safari: Yes. See comments above.
Control Sizing; Height sizing – IE 8, iOS 7, MacBook & Safari: Yes. See comments above.
Control Sizing; Column sizing – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above.
Help Text – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above.
Input Groups; Basic Example – IE 8, iOS 7, MacBook & Safari: Mostly no. See comments above.
Input Groups; Sizing – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above.
Input Groups; Checkboxes and Radio Addons – IE 8, iOS 7, MacBook & Safari: Mostly yes. See comments above.
Input Groups; Button Addons – IE 8, iOS 7, MacBook & Safari: No. See comments above.
Input Groups; Button with dropdowns – IE 8, iOS 7, MacBook & Safari: No. See comments above.
Input Groups; Segmented Buttons – IE 8, iOS 7, MacBook & Safari: No. See comments above.
IE 8, iOS 7, MacBook & Safari: Where language is used it is writer/coder controlled. They should follow writing standards to ensure parallel structure. (e.g. “Enter email” and “Enter Password” or “Email” and “Password”).
IE 8, MacBook & Safari: No. In IE the Radio buttons and checkboxes do not scale larger (125, 150, 200, 400%) when the user increases the page zoom. Oddly the controls do scale smaller when zooming out (50, 70%). Also the individual arrows in the dropdown list fields do not scale properly on page zoom either. The arrows do scale properly in the “Action” dropdown button and the “Segmented Buttons”.
E. Help users recognize, prevent and recover from errors
IE 8, iOS 7, MacBook & Safari: Generally yes. For IE 8, all grey prompt text in the fields is missing. This can be fixed with revised coding.
F. Design for human interaction
a. Is the layout/style intuitive?
IE 8, iOS 7, MacBook & Safari: Mostly yes, with layout issues (mostly in IE) and broken components noted above. Checkboxes and Radio buttons do not format vertically centered to the text next to them as they should in IE.
b. Are the interactions intuitive?
IE 8, iOS 7, MacBook & Safari: Mostly yes, with exceptions and broken components noted above.
IE 8, iOS 7, MacBook & Safari: Generally yes. Some controls make difficult touch targets in iOS 7, causing the user to have to pinch-zoom in a considerable amount in order to use them. (See comments above). In most cases the tabbing, shift-tabbing and inserting text on a keyboard work as expected. In some fields when the user hits the “Enter” key it acts as a “Submit” button, clearing the field and linking to the top of the page. This action was unexpected and may not be appropriate in all use-cases.
IE 8, iOS 7, MacBook & Safari: N/A
G. Keep it simple
IE 8, iOS 7, MacBook & Safari: Overall Yes. For IE 8, all grey prompt text in the fields is missing. This can be fixed with revised coding.
IE 8, iOS 7, MacBook & Safari: Overall Yes. But there are many small issues with proper cursor change on roll-overs.
IE 8, iOS 7, MacBook & Safari: N/A. Text is writer/coder controlled.
matyeo
commented
10 years ago Mike Atyeo (Neo Insight) will carry out an evaluation - target date 25 Mar 2014.
matyeo
commented
10 years ago @rubinahaddad @ballantr Link to Short Forms example seems to be broken: http://wet-boew.github.io/wet-boew-styleguide/new/design/forms-en.html
nschonni
commented
10 years ago @matyeo the structure of the site was changed to clarify the versions that they applied to. Replace the "new" in the URL with "v4", and "old" with v3"
matyeo
commented
10 years ago @nschonni Tx - that works. @rubinahaddad : need to change link @ top of page to: http://wet-boew.github.io/wet-boew-styleguide/v4/design/forms-en.html
matyeo
commented
10 years ago @nschonni @rubinahaddad But is that the SHORT forms example?
matyeo
commented
10 years ago Device: Samsung Galaxy S2 OS: Android 2.3.3 Browser: Firefox 27.0
NOTE: This is really a 'long form' review, as a broken/incorrect URL was given. So it covers more topics than is strictly necessary for this review! Review covers elements on: http://wet-boew.github.io/wet-boew-styleguide/v4/design/forms-en.html
YES
In Basic Example, the field highlights on touch (although I’d recommend this should be brighter). The active field has a ‘glow’ surround. The editing cursor is clear (see image).
PARTIALLY There are no hover highlights for mobile devices, so feedback is more critical. Active components highlight when touched, but highlighting could be clearer. Some components (radio buttons and check boxes) would provide more obvious feedback if they were larger, as well as having brighter feedback.
Note that the Check Box component s as described covers only basic states and interaction. There are situations where check boxes need to indicate ‘partial selection’. For example, in a hierarchy of folders, where some sub-folders are selected and others not, but where it is valuable to indicate to the user the sub-selection states. JungleDisk, for example, takes this multi-state check-box approach. See image:
NO In Basic Example, the ‘Submit’ button suffers from low contrast problems outlined in other reviews. The ‘Choose File’ button nearby has higher contrast and is more obviously a ‘button’. The ‘submit’ button should follow aspects of that design.
Low contrast buttons work well on mobile devices when there is low contrast overall, and few competing components on-screen. However, this toolkit needs to balance characteristics of the mobile device users with those of a desktop environment. In addition, where possible, the WET toolkit could move the basic component design in the direction of improved usability.
Disabled components are fairly clear on the whole, and the cursor changes help communicate their status. However, a lower-contrast fill might communicate better that fields and components are disabled. See JQuery Mobile example:
The disabled ‘Submit’ button does not give the impression it is disabled. It only looks disabled if you already KNOW what the enabled state looks like. The approach here needs to be changed.
With segmented buttons, the line dividing the segmented portion does not need to span the height of the button. When it spans the height, it visually separates the two components, reducing the perception of their relatedness. Other approaches (can’t find an example) have the line stop short of the top and bottom of the button.
YES - mostly With the exception of the multi-row selection box (see comments elsewhere in this review).
PARTIALLY ‘Button addons’ include the use of buttons on the left hand side of fields. While this is likely to cause only minor problems in some situations with mobile devices, there needs to be very clear usage guidance - e.g. to be used when the field is pre-filled, and the user’s cursor or finger is likely to already be at the left hand side of the display. Even so, the convention is field, then button, so this should be default.
Other exceptions are described elsewhere in this review.
PARTIALLY Fields allow entry, check boxes and radio buttons work as expected. ‘Choose File’ opens the system dialog box, as expected.
The scrolling Select widget has some behaviour that will be unexpected. It gives the impression that individual items within the box can be selected, but note that the targets are very small. In addition, it does not indicate that there are other (hidden) selectable options. However, on touch, a selection dialog opens – see images. This behaviour differs from the behaviour on larger displays. While this is not a major problem, it is not expected behaviour, and usage of this component in this way should be discouraged, with alternative components being used where possible.
PARTIALLY. In Basic Example, full-width fields make no sense, except on Smartphones. In general, fields widths should be just larger than the likely contents, but take into account the need to maintain a clean form layout overall; for example, a vertical series of fields might all have the same width, rather than having different widths, to reduce visual noise and to make visual scanning easier.
‘Selects’ should definitely be no wider than necessary, to minimize cursor travel on larger displays. On mobile devices, this is less of an issue, but still a good principle to follow. Until mobile access to GoC sites dominates, smaller field sizes matching likely content should be the default.
Some formatting does not work properly for mobile devices. For example, in Basic Example, the button and field layout is non-standard – see image:
PARTIALLY. In Basic Example, the ‘Submit’ button’s visual design differs from the nearby ‘Choose File’ button, for no obvious reason.
YES
NO
Touch targets for check boxes and radio buttons could be larger for mobile devices. Sometimes, these give the impression that touch has to be more accurate than it actually needs to be. In addition, small targets mean that feedback will not always be visible, as elements will be hidden under the user’s finger. Consider increasing the apparent size – and actual size – of these targets; perhaps integrating the text and buttons, similar to the approach taken in JQuery mobile.
On larger displays, the Text Area has a control that allows the user to expand the box. (Note that the drag target on this component should be bigger.) On mobile devices, the user does not have this option. WET should consider an approach similar to JQuery mobile, where the Textareas expand as more text is entered. See image:
There are various problems with display of components on this mobile device/OS/browser. These are noted elsewhere – e.g. incorrect display of field/buttons in ‘Choose file’ dialog.
In addition, there are more administrative issues, to do with accurate representation of WET examples when viewed on mobile devices.
For example, on Mobile devices, fields are no longer ‘inline’, so the description does not make sense. Perhaps use an example with two smaller fields that will still work on mobile devices. The ‘Use when’ for Field Labels does not behave well (responsive design) as window size reduces, so the section no longer appears to make sense. See images:
YES In Basic example, hints in fields work well – these disappear on typing, and re-appear if field contents are removed.
Only final states are shown in ‘Validation states’. Guidance and examples should be given for real-time error prevention – i.e. errors that appear while the user is typing, e.g. on password entry matching or not matching security requirements. In addition, validation on this page (e.g. for email address) do not seem to follow the ‘Validation States’ description – or is it simply that there are no examples of the Validation States in action?
‘Optional icons’ in Validation States should be brighter and larger.
PARTIALLY Error messages viewed were generally simple, clear, and well-positioned near the erroneous item.
Erroneous fields are highlighted – albeit in blue. To assist where there are multiple errors, fields themselves could be highlighted. At least, use the ‘input with error’ highlighting described on this component’s example page.
On Basic Example, email field validation could take place on exit of field, rather than on click of the ‘Submit’ button: On an administrative note, the email field validation error message for missing ‘@’ is repetitive.
YES
N/A – See comments in sections on ‘matching expectations’ and elsewhere.
N/A – See comments in sections on ‘matching expectations’ and elsewhere.
answer
N/A
PARTIALLY – see comments elsewhere in this review.
PARTIALLY – see comments elsewhere in this review.
YES.
ballantr
commented
10 years ago | Device | OS | Browsers |
|---|---|---|
| Laptop (24 inch Monitor) | Windows 8.1 | IE 11.0.3 |
| Laptop (24 inch Monitor) | Windows 8.1 | FF 27.0.1 |
| Laptop (24 inch Monitor) | Windows 8.1 | Chrome 33.0.1750.146 m |
There seems to be some uncertainty or change in what is required for this review. The current review is based on the example at:
http://wet-boew.github.io/v4.0-ci/demos/feedback/feedback-en.html
on March 29, 2014.
Mostly. Fields only validate when you try to submit. Immediate validation is preferable.
Validation error flags time out in Chrome. I see no value in that, and it could decrease usability.
The validation error flags in FF and IE contain no red/pink (a standard treatment)
Yes, except for validation. Validation upon Submit only.
Yes
N/A
Validation error flagging is not as per common standards, and is not compliant with the proposed validation standard elsewhere in GitHub.
Validation reporting is not consistent in message and in format across browsers:
FF:
IE:
Chrome:
The validation error reporting for emails is too leading in Chrome. It seems to help the user to create a correctly formatted bogus email address! This is one instance where helpfulness may not be a good idea!
Yes, except for validation issues
Yes, except for validation
Yes
N/A
No. FF and IE don’t scale well. The text runs into the check boxes, and the alignment goes wrong:
Also in FF when zoomed the drop-down does not behave well
It could use immediate validation
Yes, but not standard treatment. See Validation discussion on gitHub
Perhaps too much! (see C1)
Yes
Yes
Mostly. See the comments about zoomed FF and IE.
No.
Yes
Yes
Yes
nschonni
commented
10 years ago The validation looks like it is falling back to the native HTML5 validation rather than the jQuery validation. That appears to be the cause of the inconsistent messaging and visuals.
pjackson28
commented
10 years ago Agreed, anything with the dialog bubble style error messages is where native HTML5 validation was in use, meaning something was preventing the WET Form validation plugin from running at that time. The error message display is consistent across browsers when the Form validation plugin is working, but there will certainly be differences when it instead falls back to the browser's native validation and error message display.
ballantr
commented
10 years ago http://wet-boew.github.io/wet-boew-styleguide/v4/design/forms-en.html?#selects 16 April, 2014
| Device | OS | Browsers |
|---|---|---|
| Laptop (24 inch Monitor) | Windows 8.1 | IE 11.0.3 |
| Laptop (24 inch Monitor) | Windows 8.1 | FF 27.0.1 |
| Laptop (24 inch Monitor) | Windows 8.1 | Chrome 33.0.1750.146 m |
| Samsung Galaxy S2 | Android 2.3.3 | Firefox 27.0 |
| HP Desktop, Dell widescreen monitor (1920x1080) | Windows | IE Windows 8.0.7601.17514 |
| Apple iPhone 4 | iOS 7 | Mobile Safari |
| iPad mini | iOS 7 | Mobile Safari |
| MacBook Air | OS X V.10.7.5 (Lion) | Safari V.6.1.1 |
This set of examples has changed over the course of the three reviews. JxRath identified a large number of bugs – and they appear to have been fixed, but I have not tested the fixes against iOS. There remain a number of small issues – mostly around inconsistent use of styling probably defined elsewhere.
There are still some scaling problems:
The validation check mark jumps about. This is the same widget pictured in browsers of slightly different widths!
_Note: This interface is dependant on the core device or platform components (ex. keyboards, dropdown rendering etc). This component may require additional testing on platforms such as iOS, Android, Blackberry._
Please perform a heuristic review of the following component: Short forms example.
Performing a heuristic evaluation