Anyone got a oven-ready āguideā to ensure your web app works slick? Basically a do my homework for me question, since Iām quite fresh at web apps. A bit of background, the application is actually at least 2 apps, but both live underneath Vue framework, and were built by 3 different teams. I have a chance to workflow some of the navigation and UI styling that is already in place. Were can I start?
Submit buttons on all forms are disabled until the form is ready/filled sufficiently
Tab key moves to next field
Enter key defaults to the submit button
Make all controls and forms have unique IDās using a pretty naming scheme to make Selenium less painful (currently I am fixing these one at a time)
Make sure every place the user will see an error that we use āredā text next to the error area in question
Make sure the āconfirmā dialogs only interrupt the workflow and only appear when the user is about to do something irreversible
Donāt ever show dialogs with just an āOK, was done successfullyā when the server completes an action, instead only stop the flow when errors occur.
Button shape standard?
Spinner and progress consistency standard?
etc. Or am I stating the obvious, or rather simply missing a few key ones. Also keen to slip a few āaccessibilityā guidance point in here too, but I need to run a trial using Lighthouse for chrome to see what it flushes out most on.
Thanks in advance, homework due date is probably 2 weeks away.
It recommends 4 items to be visible in drop-lists, but I prefer more like having around 8 items visible in a list because āmenusā are often that deep anyway.
Hiya, Iāve got a talk on a guide to usability that I did for ministry of testing. I can give you a summary if you donāt have time to watch it. It sounds like youāre on the right track with what you are doing though.
Iām talking about a drop-list for search results, much like a google search shows, where the list populates as you type. Google show 9 or 10 hits, which in reality is a bit OTT, most of us ignore the bottom ones.
Imagine a list of like 10000 computers, so the live filter needs to show you the top relevant matches. But I think I was silly to ask for a deeper list, because only power users want everything on screen at one time, so Iām going to change my guidance to just 4 or 5 visible items.
Thanks yeah, looking forward to the DOJO session watchingā¦ grabs some coffee. I really wanted to get a guide together for my team that helps us to get structure together quickly and not fuss over artwork.
When the āartworkā person watches in late in the day usually and asks us to change the colours, icons and shapes and so on, that needs to be quick and easy stylesheet work. So long as colours chosen are safe, and our plans to work well in dark mode (every website needs a dark mode plan in my opinion) are not scuppered, they can change CSS happily.
That is a better list of buckets than the draft I posted on the work wiki yesterday, Iām stealing those. You are the boss @melissafisher !
This is considered bad form (excuse the pun). Countless usability studies have shown that disabling submit buttons puts the onus on users to figure out why they canāt proceed and often they assume the page is broken. Better to use a permissive button and draw the userās attention to the missing or erroneous input via a modal.
Well spotted, Iāll focus on this one in my guide to the team. I want us to do this by using an accent on fields that are mandatory , in some guides this is by placing a * next to the needed field, but in some UX, this is by adding a extra bold border to mandatory fields and controls. This gets tricky to show well with radio buttons , hence the need to go bold for mandatory inputs feels better?
Keeping the amount of stuff on a page small gets super important when you do this, because if a form is large, and a user clicks the button, the form must never scroll back to the first input that they missed. Especially if they are using your app on a phone, Bleeeegh. Flashing a missing input is an option, and this is kind of why I asked about this as a āhome work questionā. Iām a developer-turned-tester and so all this UX stuff is totally overwhelming, and threatens to almost eat into my real bug-detection time. Very good points to bring in, thanks @gingerbbm
I assume youāre after only low-level UX type stuff and not higher-level UX stuff. By that, I mean the UX stuff thatās closest to UI design, rather than the more abstract stuff. So youāre not testing how well the system matches up with the userās mental models and goals, it doesnāt matter about how the tool fits in with a bigger flow (as in customer journey mapping) etc.
Sorry if this is already covered by what e.g. Melissa says in her talk (which I havenāt seen). On top of what people have already said here, I would add minimising user work. So, if there is only one option for a parameter (when sometimes there can be > 1), donāt force the user to pick that one thing from a list. Instead, pick it for them. And, more generally, if there are sensible defaults you should use them. If you happen to know what the majority of users will want to pick, consider picking those (while still making it easy to change away from the defaults).
Make it easy for the user to change their mind. Make it easy for the user to know where they are, both in a static sense (Iām on page X, which is part of section Y, and from here I can easily go to related places A, B and C), but also in a dynamic sense (Iām on step 3 of 5 in some process). When there is a multi-page process, to borrow programming terms, you want loose coupling between pages and high cohesion within pages. I.e. the break between one page and the next should correspond to stages in the problem as defined by the user rather than falling in the middle of one mental chunk (so the user doesnāt get confused why they have to click Next / Submit), and everything on a page should feel like it belongs with everything else on that page (so the user isnāt confused when searching for stuff on the page).
The asterisk is the de-facto standard for signifying a mandatory field, although personally I think itās ugly and meaningless if youāve never seen the pattern before. In my practice Iāve found that itās usually the optional fields in a form that are fewer in number, so better to call those out (with an ā(optional)ā in the label) rather than scattergun asterisks.
I donāt think Iāve ever seen the use of a thicker border to denote mandatory fields, or if I have I didnāt twig the significance!
In all the above Iām talking about default form state, not error states.
The gov.uk website is a great example of forms done well: they use very brief steps and donāt mind about numerous steps in a flow. Try the passport application, for instance. This makes handling of errors easier, but they donāt scrimp on that interaction design either. Itās inspirational.
Will definitely have a run through the .gov.uk site for good examples, I hate the asterisks way of denoting mandatory, and saw in one place someone using colour to denote mandatory fields. But since I donāt think colour is a good way of doing that I was guessing at going with bold borders instead, but
(optional)
Is just so much neater, and friendlier, friendly tone is important I believe.
@bobs Yes Melissa does touch on āminimisingā work for users, but not on the pick lists and defaults thing. Iām probably going to try going through and test a lot of this manually I guess.
Wizards and pages are hard to get right, these days designs all tend towards as little as possible on each page as possible. So thatās another goal to aspire to. This idea of loose coupling and high cohesiveness sounds like something to grasp and understand at a higher level as I progress more on the journey to get this to work. Want to get that right early to prevent having to rewrite flows.
Sorry not to explain myself better, and Melissa is the expert here so please go with what she says .
Cohesion and coupling are good tools for working out where to draw boundaries between lumps of code e.g. methods, packages, micro-services. Cohesion refers to whatās inside a single lump of code. Coupling refers to how one lump relates to other lumps.
If a method is a dumping ground for assorted stuff that doesnāt belong together, then that method has low cohesion. It doesnāt have a single purpose or identity, which makes it harder to understand, gives it more reasons to change (due to any of its many purposes changing) etc. Low cohesion suggests that the method should be split up into bits, with each bit having a stronger identity and one purpose i.e. higher cohesion.
Coupling is how much is one method tied to others. If the inner details of one method changing forces another method to change, then they are tightly coupled. Itās better if a method depends on only the interface of other methods - as long as the interfaces donāt change, then the first method shouldnāt have to change.
I was using them as metaphors to describe wizards etc. One problem is that one stage of a wizard is a random assortment of fields, with little that ties them together. The user will find it hard to understand the purpose of this stage. Can you put a single title on the page that represents everything on the page? I was calling this low cohesion.
Another problem is that a user fills in thing A on one screen, clicks Next, and tries to fill in thing B on the next page. But A and B are very related, so seeing the answer to A might help with the answer to B. Or the user might want to change their answer to A based on the options available for B etc. I was calling this a tight coupling between A and B / the two pages. It suggests that A and B should be on the same page, or something else done to address how strongly related A and B are.
Just to weigh in on this: colour alone is never a good way to denote anything in the UI for reasons of accessibility. As soon as a colourblind person comes along, all bets are off. Thatās why error messages are often in red but also have some kind of accompanying iconography. We call this approach redundancy.
Yes @gingerbbmredundancy. I saw that used in something recently and it looked cute, but now it makes much more sense to use icons as well as colour.
@bobs As for experts, well I suspect my fear is that you only become an expert at what your customers are doing when you have metrics to support and real observations to support design changes. Will have to run a few in-house sessions with non-engineers in the company to find out what the user experience really works out or not. I think when it comes to UI, the cohesion of the code can sometimes prevent code re-use for UI flows that are similar enough to share code or at least to share pattern.
I donāt think that code coupling problems map into the user experience directly, but it has a chance of doing so. And as such Iām more keen to jump to keeping the UI as low on coupling as possible while making it look cohesive to the user really. Only user feedback is going to tell me if Iām driving in the right direction.
Iāve just looked at our product, at a wizard with 3 stages and each stage has about a dozen fields. (Itās an editor for admin users, rather than something that a casual user might use only rarely, so the many things per page isnāt so bad.)
Iāve noticed that related things are grouped together with a heading and sections within the page are separated with horizontal lines. The various sections make sense to go together (although they could in theory be split into different pages).
I donāt think itās often the case that someone creates a new page or entire flow with bad cohesion or coupling, but it can be an instance of ādeath by a thousand cutsā. People have repeatedly added ājustā one more field here and there, without reviewing how the whole thing works. E.g. new fields could be added to the bottom of the page because thatās easiest, rather than existing things shuffled about to give a proper home for the new thing.
Also, my point wasnāt actually about the code - itās using code properties as a metaphor for UX properties. Iām aware that this is moving up the levels of UX away from important details such as how mandatory / optional is communicated. The key thing is the user, their needs, their mental models etc. Does the UX map to those. Anything else is just a means to an end. So (as you say) to know if youāre doing it right, you need to talk to users, ask them what theyāre trying to do, watch them use the product to see where it does and doesnāt fit well etc.
Thanks for calling me an expert! I understand the basics of what to look for from experience and also go with my gut feeling. If something feels frustrating, then Iād share that with the team and work through to find a solution together. Thereās not always one size that fits all. It depends what it is. I have more to learn in this area
