I'm also interested in more general thoughts, but here is my specific problem. In an ASP.NET web app, I am connecting to a 3rd-party via API. The 3rd-party requires that the user login and answer a few configuration questions to set this up. All of the questions except one the user can just choose the default. On one question if the user chooses the default option, my app won't work with the 3rd-party. It is a limitation of their API. It is on their list to fix, but who knows when or if they actually will?
So what is the most effective way to give the user instructions in my app that they will follow once they go to this other site? Right now I have a screenshot with the option circled in red, follow by some descriptive text. What other techniques have you used in a similar situation?
Red text is the default mechanic in UI design to indicate importance (which is why it's used for errors so often).
Asterisks are the default choice for indicating required input.
Avoid flashing, and other garish-looking visual mechanics.
If this extends beyond a one-time inquiry, you should look at reading some good GUI books, like Don't Make Me Think: A Common Sense Approach to Web Usability and Designing Web Usability, both seminal books in the field.
I think you're headed in the right direction. I would make sure that your illustrative screenshot is large and easy to see the relevant details on. Also, some highlighted (classic yellow background ala 37 signals?) text to emphasize the importance of NOT selecting the offending option would be helpful.
Also, make this screenshot and highlighted instruction text, the VERY last thing they see before you forward them to or present the 3rd party site. Maybe make the action link (button, link, etc.) explicitly outline their acknowledgment of the thing not to do.
Maybe even, have fun with the caption like...
"I understand that choosing the default option above won't work."
Just some thoughts.
Unfortunately, nothing you can do will prevent idiots from choosing the wrong thing anyway. Basically, you can't make it idiot-proof.
This is more for GUIs but (depending on how critical this is) you can force users to type "I will choose xyz" before a redirect.
Is there a way to set a default on your end to get around this problem altogether? For example, picking some random setting initially that they could change in a profile of some kind that you can store on your end.
I've typically seen a red asterik(*) used for marking required fields on web forms if you want to not pre-select some value for the user for another way to try to solve this issue.
I know you want abstract, generalizations but there is no one true answer for what you're asking. I mean, what kind of content are we dealing with? Is the content broken up over multiple pages (or should it)? What kind of users generally use the form?
I know I've dealt with similar problems in dozens of different ways. Ideally you want not start treating your users as complete retards straight out of the box (just move to that progressively as they fail tasks), but you also want to be clear on what's going on.
The really high level (and obvious) ideal is that you want to make the instructions stand out to your punters. Colour change and standard icons do this (often poorly). However, changing the background colour of instruction text (to say a light gray) with a large icon (like a yellow sign with an exclamation mark) tends to focus the eye.
Another idea in your situation is to break the content in two. This might be done physically (press next to continue) or you might just colour code that hole part of the element a different colour to notify the user that they need to treat this differently.
Related
WCAG's definition of functionality
processes and outcomes achievable through user action
link to source
Following WCAG's definition for "functionality", it seems intuitive that just as functional elements should always be keyboard focusable, non-functional elements should not.
However, in accessibility matter, naïve intuition can be misleading. As I could not find any definitive guidelines or failure criteria for this on W3C site, I'm asking here:
Is it ever a good practice to make a non-functional element keyboard focusable?
If there are W3C or other official standards supporting your answer, please mention them.
Note 1: Please do not provide scrollable but otherwise non-interactive elements as an example - for our purpose, scrolling is an interaction.
Note 2: Somewhat related, but not a duplicate of the question "Should text ever be focusable for accessibility? I'm specifically thinking about key-value pairs", also somewhat similar to this question: "Accesibility vs. read only inputs", but that was asked in 2013, and its single answer isn't authoritative enough IMO (and I'm guessing is incorrect for today's accessibility conventions).
Is it ever a good practice to make a non-functional element keyboard focusable?
Yes, but in very rare circumstances.
Oh, you want a longer answer? 😋
Tab panels are a prime example (and the only concrete example I can think of) of when tabindex="0" is useful.
In this instance it serves no purpose other than to allow a user to easily navigate to the panel so they can read it's contents.
This is demonstrated and explained on the W3 Example of manual tab activation page.
The reason this is suggested is that it functions in a similar fashion to a "skip link".
All the tabs are operable with the arrow keys, but the whole tab list is one tab stop.
Then when a user has opened the tab they want to read they can press Tab in order to jump to the content instead of having to read out the rest of the tab options.
Some "fluffy" examples
The only other time I have seen this used and it felt correct is in a "live chat" application when you could Alt + Tab through the conversation items. This felt better than using headings, sections or other ways we may make something keyboard navigable (and arrow keys didn't feel intuitive).
One last one that comes to mind would be data tables, sometimes you may want a table to receive focus so that a user can navigate by arrow keys. So it receives focus to activate the component and let people know it is interactive via keyboard.
I am thinking of someone not using assistive tech but who uses the keyboard due to mobility impairments in this instance.
However that is just speculation I have never implemented that myself and if I did it would probably be because a highlighted row changes a graph etc. (which I am sure you would count as interactive!)
Any official guidance?
With regards to official guidance, I doubt you will find something concrete. Obviously WCAG 2.4.3 - Focus Order does come into play here as adding a tabindex="0" to everything is not a "logical focus order", but it will not give you a definitive answer as it has to allow for custom components etc.
I am afraid this one is a "best practices" rather than a rules scenario. You would probably still pass WCAG if every item on the page had a tabindex="0" as WCAG doesn't focus on user experience but rather on whether something can be used at all. However nobody who relies on assistive tech would want to use the page with a hundred tabindex="0"!
If you adopt the principle that the focus should always be visible, then situations can exist in which the only way to make that be true is to put a non-interactive element into focus. A skip-navigation link needs a destination after the navigation header, but it is possible that nothing in the main region is interactive. A modal dialog, when dismissed, needs to have a focal successor, but its dismissal may cause the triggering element to disappear and leave no other element, or at least no intuitively reasonable successor element, interactive.
Another scenario: A user action could cause informative messages (hints, clues, annotations, etc.) to be inserted at various points throught a view. They might all be in live regions, but that would not make them easy to locate. Making them focusable would allow the user to navigate through them sequentially, ensuring that none of them is missed and no laborious searching is required.
I've seen a few error dialogs implemented this way, where the only interactive element on the dialog was the OK button, and they decided to set tabindex="0" on the message text.
This meant they could put focus on the OK button when the dialog opened, for faster dismissal, yet allow screen reader users to tab to the message text. This was probably more common before we had role="dialog". Overall I would say that making a noninteractive element focusable should be situational and rare. Don't do anything that would confuse users. But if it results in something that's intuitive and easier to use, I would say go for it.
From a User Interface design point of view when is it better to disable a control or to completely hide it. I have attached an example. In both case if the "Enable ASP.NET" checkbox is clicked the "Select. Net Version selector is enabled.
I would argue that it's almost always best to just disable. Hiding controls means you're leaving a portion of your functionality/configurability a mystery to the end-user. Unless there's a compelling reason to keep users in the dark, I wouldn't.
Your example of a checkbox that enables/disables or hides/unhides a dropdown box is a good one. If users aren't aware that checking the box allows them to select further options, they may never check it and find out, because they don't realize the option they're looking for is there.
Many of us, as developers, come from the "try everything" mindset when it comes to using a piece of software. Normal users don't think that way, and that's not a bad thing, either. It just means we have to keep in mind that not everybody will do what it takes to discover a piece of UI that's been hidden. Leaving it visible but disabled lets them see that there's something there for the having should they decide they want/need to use it, rather than leaving them either wondering if the software does something or never even considering that it might.
This really depends on the context of the example. In this case there is some value associated with disabling the control as it provides a visual affordance that enabling the ASP .Net checkbox will have a determinable outcome.
If the outcome of the checkbox is actually a whole series of non related suboptions or the parent control was a dropdownlist which determines which child elements become available then it would be better to hide / show only those elements that are appropriate to the current selection.
One other point, if you are describing "hiding" the controls as control.visible = false in code rather than display:none then remember that the output will actually not be rendered into the browser at all. This may be a concern if you are catering for disabled users with browsers requiring stricter accessibility requirements etc.
To me that depends on user knowledge. If the user knows what should follow I tend to give them as much information as possible so I would show it disabled. If the user is clueless as to what follows I hide as much as possible. Sometimes I do different things on user role and sometimes it depends on the average user of the application and their expected understanding of the underlying issues.
hth,
\ ^ / i l l
I prefer to disabled the control, so the user can see that he may have something to fill out. But it can be usefull to hide it if you are restricted on space.
It really depends on the situation
Stackoverflow members,
How do you currently find the balance between javascript and code behind. I have recently come across some extremely bad (in my eyes) legacy code that lends itself to chaos (someHugeJavafile.js) which contains a lot of the logic used in many of the pages.
Let's say for example that you have a Form that you need to complete.
1. Personal Details
2. Address Information
3. Little bit more about yourself
You don't want to overload the person with all the fields at once, so you decide to split it up into steps.
Do you create separate pages for Personal Details, Address Information and a Little bit more about yourself.
Do you create controls for each and hide and show them on a postback or using some update panel?
Do you use jQuery and do some checking to ensure that the person has completed the required fields for the step and show the new "section" by using .show()?
How do you usually find the balance?
First of all, let's step back on this for a moment:
Is there a CMS behind the site that should be considered when creating this form? Many sites will use some system for managing content and this shouldn't be forgotten or ignored at first glance to my mind.
Is there a reason for having 3 separate parts to the form? I may set up a Wizard control to go through each step but this is presuming that the same outline would work and that the trade-offs in using this are OK. If not, controls would be the next logical size as I don't think a complete page is worth adopting here.
While Javscript validation is a good idea, there may be some browsers with JavaScript disabled that should be considered here. Should this be supported? Warned about the form needing Javascript to be supported?
Balance is in the eye of the beholder, and every project is different.
Consider outlining general themes for your project. For example: "We're going to do all form validation client-side." or "We're going to have a 0 refresh policy, meaning all forms will submit via AJAX." etc.
Having themes helps answers questions like the one you posted and keeps future developers looking in the right places for the right code.
When in doubt, try to see your code through the eyes of someone who has never seen it before (or as is often the case, yourself 2 to 3 years down the road), and ask yourself: "Based on the rest of the code, where would i look for this function?"
Personally, I like option number 3, but that's just because it fits best with the project I'm currently working on and I have no need to postback or create additional pages.
this is my firts post here ever.
I have to develop an aplication for a group of people with special needs. The functionality is really trivial, however, i have no clue of how to do the interface for them to be able to use it.
Their intelectual habilities are perfect, they are actually studying high school, but one of them types with his nose which needless to say, is very dificult and another one types reaaaaaaally slowly with only one of his fingers and neither can use the mouse.
I was wondering if i could use javascript to develop a usable interface, based on huge grids or something like that or maybe you guys have a better idea.
Political incorrectness aside, why don't you ask them? You're talking about accessibility here, if they're using computers they must be able to tell you about what they like or dislike about user interfaces that they've encountered.
I'm going to split my answer into two parts - design and implementation.
From a design perspective, it's important not to be intimidated by the fact that the users use a computer in a different manner. Treat this like any other project. Observe how they currently use other apps, and ask about the kind of things that they find helpful, or have difficulty with. If they claim nothing is difficult, ask a teacher or assistant, who will be familiar with the kind of things they struggle with.
Once you've started implementation, try an idea and get initial feedback. If you simply ask how they find the prototype, they'll likely say it's ok. Instead, try observing them using it without saying anything or giving guidance. If they get stuck, let them find their own solution to the problem. If appropriate, you could ask the user to speak their thoughts out loud (e.g. "I need to save this form, so I'm scrolling to the bottom, and clicking save").
On the development side, try to use web standards (valid HTML, CSS and Javascript). People often point to the "Web Content Accessibility Guidelines 2.0" (WCAG2) but this is quite turse and hard to understand; there are many more friendly articles on "Web Accessibility".
Someone with a physical disability is likely to use an alternate input device, such as a "Switch", onscreen keyboard, head-tracking device, a device for pushing keys on the keyboard, or speech recognition. Many of these methods involve simulating the keyboard, so by far the most important thing is to consider the accessibility of your site without using a mouse. For example, try tabbing through the page to see if you can access all elements in a reasonable amount of time. Consider using the acesskey attribute to provide an easy way to jump to different parts of the page (using 0 through 9 is often recommended so you don't interfere with browser shortcuts).
Also make sure that no part of your site is time-dependant, as different users may take different amounts of time to perform a task. For example, don't use the onchange Javascript event to update a page based on a listbox selection. Ensure you have alt text for images, so it's accessible for speech recognition. make the pages short enough so that excessive scrolling isn't required, but not so short as to require following lots of links.
Those are just some ideas to get your mind going in the right direction - but there are many accessibility resources on the internet - steal freely, and don't reinvent the wheel.
I realise I haven't addressed your question about Javascript - that's because I think it's probably one of the less important considerations. If possible, use Progressive Enhancement techniques to make the site work with and without Javascript. You might also look into the WAI-Aria standard for giving semantics to your Javascript.
And finally, to reiterate my initial point - make something simple, show it to the users, tweek, and show again.
It doesn't really matter what technology you use. Use whichever suites you.
But, make sure that you make UI components BIG in size(Bigger buttons, bigger font, bold font, coloured font(are there any colour blind?). This is for the ease of use of people (you said someone types with nose).
Also, better to have audio as informative source along with the usual screen display whenever some wrong action is performed on the application. This way visually impaired people will be assisted more.
Do it well, you are doing a divine job.
The first thing that you should read up on is the Web Content Accessibility Guidelines written up by the W3C.
In a nutshell this document describes the basic principles for people with disabilities in general.
For your needs regarding persons with special needs, you might want to look at Jakob Nielsen's article on Website Usability for Children, wherein principles of web design for young children or people with otherwise limited cognitive ability are outlined.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
Concerning pages that build a web application:
Lately, I have found myself creating web pages that are simpler than the ones I used to. Before, I would try to jam as much functionality into a single page as I could to prevent from having lots of pages.
I am starting to realize that this was just making things way more complex, convoluted, and confusing than it had to be. Why not have more pages? I think the reason that I was doing this was because I didn't want the user to have to browse to other pages; just to have all the functionality they needed on a single page.
Well, these good intentions turned into an overly confusing interface for the user and very unmanageable source code. I am a new developer and I am trying to be very reflective of what I am doing so that I can improve. If it makes a difference, I am developing in ASP.net (though these are probably considerations for any platform).
My questions are:
Am I overthinking these things?
Has anyone else found themselves doing this?
Where is the happy medium?
There is no expert who can give you a rule that works in all places at all times. I have been known in my industry for years for "easy" interfaces and we've won significant amounts of business for it (as well as 5 "Best in Class" awards). I have also had people within my company and outside of it tell me - for years - that they like my work but wish that I would "jazz it up" with more graphics and such. What always amazes me is how little connection people see between the two.
So...a few rules of thumb:
A page should do one main thing.
A page may well have multiple links related to the main thing
Menuing and link layout should be consistent across pages
Simpler is better than more complex
Pages should be visually appealing and inviting
Rule 4 is more important than rule 5.
For example, my product provides an interface that lets people define classes and events to be displayed in a calendar. I could have one page that lets you Review, Add, Update, Delete and Edit the classes. Indeed, in some simpler areas, I've used the gridview to let people manage everything in a grid. However, classes have too much information to do this and still follow the rules above.
So,
The main idea is: "Here is a list of classes for this location"
The links are "Add New" shown above and to the right of the grid, Change and Delete are links within each row. This is consistent across the app.
Menuing for the system as a whole is always across the right/top. Nothing else appears on the class/event page except for standard elements common to all pages (a logo, a header, a footer).
The grid is nicely styled but there are no spurious graphics (4,5,6)
A few last things about UIs and graphic design.
First, develop your own vision and be consistent across pages and apps.
Second, do not be afraid of simplicity.
Next, when soliciting advice from others keep in mind that you do not want their advice - you want their impressions: you want to understand the way they perceive the interface. Advice is sometimes good but, more often than not, actually harmful. In my experience, everyone thinks that they are a UI expert.
When you do your hallway (or formal) useability testing you should discount almost all advice to the effect that "you should make that stand out more." As you'll see, it will quickly become "and that," "and that," "and the other." If you follow this advice, you'll end up with a mess due to Brittingham's first rule of design: If everything is important than nothing is. (There you go: when explaining why you can't make someone stand out more, just tell them that "it violates Brittingham's first rule of design!")
Hope this helps!
You hit the nail on the head. Use the KISS principle. (Keep It Simple Stupid)
I've done this in the past as well and not only does it make for a hideous UI, but confusing as to what operations you can do on the page due to having too much functionality. I've often found in testing that I did not have enough checks to see if the user could perform a certain operation based on the state of the data.
It's easy enough in ASP.Net to write several pages that do simple tasks and then link them together with Response.Redirect or Server.Transfer. Now all I try to achieve on any given page is what the design specs say. So if my page is just a search page, that's all I give. If the user wants to see the details of an item that was returned in the search, then I send them to an itemDetails.aspx page.
You've broken a wall that most software developers have, the one that was blocking your view on usability before. A lot of developers don't really think about it and try to make it easier for them by stuffing functionality in one window, web page or whatever.
The thing is once you start designing software from the user's point of view, i.e. making it easier, several things start to become clear. One is the issue of code maintenance, that code is easily more managable to work on if you don't stuff everything in one giant class or whatever travesty you've been doing. The other is usability itself, that you start to think how the user is actually using your application through the graphical interface. Third is avoiding requirements or scope creep where you stop developing functionality that the user doesn't need.
We as users want simplicity partly because we don't want to spend most of our time muddling through a bad UI when we can get our work done faster with a simple and slick UI. That makes it for us software developers the right thing to do, to think through your design on all levels... that and specs always lie.
Definitely agree: most attempts at writing pages/forms that do too much have resulted in
bugs and rewrites. Problems occur with keeping all parts valid/synchronized,
excess managing of users' expectations ("I've entered a bill number here and clicked "find person" there but it gives an error message. Why?") when the two are logically separate. These questions cannot arise if only the valid options are visible,
Formatting/layout issues: In ASP.NET pages, trying to layout independent User Controls turns out to be a nightmare ("But we really want all the buttons vertically aligned!" in separate user controls. Good luck with that.)
I'd consider webpages with more than one functionality only if the target audience consists of domain experts, i.e. people that need lots of functionality on one page for better productivity (think data-entry or financial software with lots of variables).
Even then, most of the time, it's possible separate pages into single units.
No
Yes - me
I found the happy medium was to use Masterpages, and using it in a way that was familiar to IFrames. That I could have a lots of functionality combined well together. There is a more interesting way of doing this with WPF/Silverlight called Prism
The amount of functionality on a page is usually not determined by you but by your customer. If the customer demands a single page to update some VeryComplexObject, you're likely to end up with an aspx page that has a significant number of lines. Main reason is that you simply have a lot of event handlers for all actions on the page.
Whether that page is complex is entirely up to you. You should always attempt to make your code-behind file as simple and clean as possible. Some suggestions in that direction:
Move all business code to another application layer.
Use ObjectDataSource for providing data to data-bound controls such as ListView, GridView, Repeater, ... Delegating loading of data to a dedicated object prevents a lot of overhead in your aspx.cs file.
Another suggestion is to use user controls to implement portions of your page. You would usually only do this when you can reuse the user control, but it can also be of great help reducing page complexity (both of your code-behind file as well as your aspx).
Sometimes I think we are all guilty of forgetting just who it is that we develop our applications for. It isn't always easy as a developer to be able to take a step back and have a look at your application as a user might do so. This is why big companies employee hundreds of people to do this for them and they don't always get it right.
Usability is a massive subject but it is defiantly something that all developers need to keep in mind. It has taken me a long time to learn this but when tackling any development task I always try to think about how my users are going to interact with what I am writing. This will make a difference to all levels of your development.
I would suggest reading Don't Make Me Think by Steve Krug. This book won't take you an age to read and it puts across some fantastic ideas that can help you to develop applications that are much easier to use and understand.
I always find that once I have thought about the user experience the decisions about what my web pages are going to do and how they are going to interact are much easier to make.
Maybe you should ask the people who are using your site. Or better yet, just watch people use your site. I think that would tell you if your site is designed well, or if you need to change it.