Recently I was asked for an opinion on a website, to see if the workflow was natural and easy to follow. It was nice to be involved in a very small way, and although I won’t comment on the workflow itself. I thought it would be nice to highlight a few suggestions that I made, and talk about why I believe them to be better choices.
What follows are two images of forms, both have the original website on the left, and on the right is my mock-up of what changes I would be keen to carry out.
The image upload
The first image is looking at the ‘cover story’ creation. I misunderstood this when I saw this, and instantly assumed that it was where you would upload an object. In fact, the intention for this section was to upload a single object, which would then act as a featured image to the story.
The biggest issue I have here is the fact that the initial interface allows for one method of interaction, and that is a clumsy one at best:
Some people with poor fine motor control have difficulties making small movements and remaining steady. For this group of people, the dexterity requirements to accurately select and move an object using a pointing device can cause them problems, and they benefit from a keyboard equivalent being made available to allow them to use such functionality in a different way.
— Opera article, “Accessible drag and drop using WAI-ARIA”
If you read the above article, you will see that it is not impossible to make drag and drop accessible for those who don’t use a mouse, but there are other input methods that I believe would either be tricky or cumbersome. It is a question that others are asking with regards to drag and drop, and accessibility.
My suggested improvement would be to add an alternative to drag and drop. For users who want to use this method then the option is there, but it should always be an option.
For myself, I rarely used drag and drop on anything that requires dragging and dropping from more than one window. The only reason this has changed recently, is the fact that I now have two large screens. However, when I am on my old laptop, to drag and drop a file from Windows Explorer into a Chrome upload box is painful. It generally means that I resize my browser, which is a lot of effort for something that should be easy.
Although I misinterpreted the purpose of the above upload box, I think the method is still valid.
The second suggested change on this image is nowhere near as vital as the first, but I still believe that it is worthwhile. That change would mean replacing the ‘Step 1/3’ notification with a progress bar, supported with a percentage indicator.
The reason behind this change is not only that it is visually more appealing, but as many articles suggest, the gamification of the progress bar is rife with benefits.
Humans love progress bars, if you see a progress bar, you want to complete it.
— Seth Priebatsch, SCVNGR
It turns out that my profile completeness was only about 25 percent. But, by adding another position I could be 40 percent complete. That was a simple enough request. So, I added my last employer. Then I got another prompt: “Adding a summary will bring you to 55 percent.” So I did that.
— Stephen P. Anderson, Seductive Interaction Design
I intentionally felt that opening the form was step 1 of 4, and not step 1 of 3, so immediately the visitor would see that they were 25% of the way through the form already, rather than at an uninspiring 0%. When the user uploads the initial image, the form would already be at 50%. I don’t know if there has been any user research with regards to using a progress bar, or the alternative “step 1 of 3” method, but I would feel that the visual progress bar and supporting percentage indicator would have a lower drop-off and higher completion.
The story creation page
This second image is the story creation page, the area where you fill in the content, and describe the story that you are creating. I have not focused on the small input areas, but rather the issues with placeholder text, and making interaction easier.
The first thing that you may notice is that there are no
<label>s at all on the first screenshot. There is a reliance simply on the
<placeholder> text. This is bad for a number of reasons, browser support is good, but weak in IE, screen readers will pick it up on most browsers, but there are more issues. The default text color contrast fails the W3C’s color contrast guidelines, meaning that the text would need styling to pass these guidelines. Unfortunately, support for this is still not perfect
<placeholder>attribute should not be used as an alternative to a
— W3C Guidelines
In short: Reliance on a
<placeholder> is bad.
<label>s at the top of the forms. This is once again due to being better for accessibility. Not only are forms completed faster if the
<label> is above the
<input>, but also the proximity and placement is better for people who may have cognitive disabilities. Thirdly, for partially sighted users who may magnify the text, the form placement will still be easily accessible by scrolling up/down, and not left/right as you would have if the
<input> was placed to the right.
The other thing I introduced here, that has not already been discussed, is the “suggested tags” area. In all honesty, this is the suggestion that I would need to do more research into before suggesting it as an improvement. I am not sure if there would be any SEO impacts on this…
I have opinions of my own, strong opinions, but I don’t always agree with them.
— George H.W. Bush
… the thought process behind it was that it should show suggested tags, to make this easier for the user, and to also reduce duplication or misspelled words.
This has been a fairly substantial post, but I did want to just share the process. Doing work on the web is often viewed simply by what appears on the screen, and as you will see, it isn’t like that at all!Share