I am in the process of beginning work on several ASP.NET custom controls. I was wondering if I could get some input on your guys/girls thoughts on how you apply styling to your controls.
I would rather push it so CSS, so for the few controls I have done in the past, I have simply stuck a string property which allows you so type in the string which in then slung in a "style" attribute when rendering. I know I could also use the "CSSClass" property and apply the "class" attribute.
I have not done much in the way of creating a "proper" Style property (in which you actually save the style object, and use the designer to specify its values). This to me seems like a lot of work, and TBH, I hate the Style editor UI and would much rather type in the CSS/class name to apply..
What are your thoughts on this?
Note: This is kind of subjective - so to be clear:
The accepted answer will be the one that:
Offers the pro's and con's of the various approaches.
Opinions are welcome, but a good answer should be constructive.
Backs it up with some real-world knowledge/experience.
There is nothing wrong with subjectivity. There is a problem with people being subjective and not thinking, being constructive or actually providing some insight and experience.
>>DO NOT<< tag this as "subjective" - that tag is a waste of time. "subjective" is not a technology or a category that people will look for. Fix the question rather than brush it off.
It would depend on how the custom controls are being used - A commercial, re-distributable control should be compliant with the VS IDE, and behave the way users expect it to when they implement the control.
On the other hand there is no point in wasting a lot of time to get styling to work if you or your team are the only ones to use the control, so long as it's styling works in a sane way.
Most of the custom controls I have implemented use a property to define the controls look and feel or just expose the controls' members own CSSClass properties.
The argument comes down to consistency vs. time - any element should use consistent styling mechanisms, if strapped for time, use a string method if not, implement a more complex / IDE friendly mechanism.
I think you should consider your "target market" for the custom control, e.g., the people who will use it.
If it's an internal custom control, you can pretty much mandate the use of one or the other: if it's internal to the company you will have the ability to enforce its consistency.
If it's meant for commercial consumption, however, it is required that you give an option to provide a way to use either style or class. Case in point: the ASP.NET site navigation controls, e.g., SiteMapPath, Menu, Treeview. They have a bunch of properties exposed to allow either styles, classes, or a combination of both to each aspect of the controls' appearance.
Related
I'm tasked with evaluating some legacy web pages (classic asp) for accessibility. You can assume the HTML is not perfectly formed and that it's loaded with inline javascript and that we make use of javascript libraries that vomit HTML to create dynamic features. It's a circus in there.
While I recognize that the obvious answer is to re-write the page(s), that's not an option in our given time tables. So I'm trying to find the best way to make the pages work with a screen reader. Here's what I think I know.
We can use JAWS scripting to instruct the browser how to read the page.
We can use ARIA attributes to give the pages better organization and structure.
Specifically, I'm trying to figure out:
Question 1) If a JAWS script is present, will it be used exclusively by the browser/screen reader and ignore any improvements I make in the underling HTML structure?
Question 2) Could some well-place ARIA attributes give the page enough structure so that the default screen reader properties will work in an acceptable manner (without a JAWS script).
Question 3) I suspect the tough answer is that I would need to do both, which I'm trying to avoid because we barely have the capacity to do just one. But we don't want to lose a customer, of course. :-(
Many thanks for any input.
Instead of explaining only to JAWS how to access your pages, use JavaScript to explain it to any Assistive Technology (AT) for the web. I expect the same effort, while it will profit way more users.
In a JAWS script you would need to describe ways to access DOM nodes that are not accessible. That would include
speaking out information that you have to find elsewhere on the page
adding keyboard navigation where it's missing
Both can be done in JavaScript, probably even easier (you'll need to address DOM elements).
What you will need to avoid is restructuring the DOM and changes to classes, since those are most likely used by the scripts that generate them.
But I'd expect that adding attributes and keyboard handlers will do no harm to the existing scripts. Beware of already existing handlers for focus or keyboard events, though.
I would recommend making a list of attributes and handlers you suspect to conflict with the existing scripts, and searching the scripts for these, like onkeypress or onfocus event handlers.
The absolute best way to make your application/site accessible is to use semantic HTML. It doesn't matter if that HTML is generated by asp or jsp or whatever.
If you have a table, use a <table>.
If you have a heading, use an <h2>.
If you have a list, use a <ul>.
Use <section>, <article>, <nav>, <aside>, <header>, <footer>, etc
That's how you create structure on your page that a screen reader user will appreciate.
If you can't use native HTML, then fall back to ARIA, but treat it like salt. A little bit greatly enhances the flavor but too much spoils the meal.
If you can't use a native <h2>, then make sure you use the appropriate role and attributes.
<div role="heading" aria-level="2">this is my custom h2</div>
If you can't use a native <header>, then make sure you use the appropriate role and attributes.
<div role="banner">my header stuff goes in here</div>
I would recommend totally forgetting about JAWS scripts. It doesn't matter if that's what the customer thinks they should focus us. It's not about that customer. It's about that customer's customers. The end users. They should be able to use whatever screen reader they are used to using and most comfortable with. That's the whole purpose of accessibility - making the site usable and accessible by as many people as possible using whatever assistive technology they are used to using.
Following the Web Content Accessibility Guidelines (WCAG) will lead you to that result.
Can some one please tell me if I should use user controls in my project as much as I can? Ff so why and if not why not?
It's an interesting question; but think of it this way.
You've just written a table, listing all of your users. You show this on the List Users page of your website.
On the "Find User" page, you might want to be able to show a list of users. Do you rewrite the same HTML, code, javascript, CSS as before? Or do you reuse the control, this time adding the ability to filter by a user name or other attributes?
Essentially, user controls are there to package up reusable bits of your website. Rather than repeating the same code everywhere, you can package it up in a user control, and simply add it to any page you want just by adding the appropriate tag.
Also, you have just made ONE control in your project responsible for dealing with some functionality - all of the logic for it is in one place and separated from other code. This is an important concept too, as it stops all of your code being jumbled together. In the users example, you can interact with a list of users through an interface, rather than mixing it with other code that might do different things. This is called SRP and can be a good thing.
As a practical example, we have a control that shows a list of our products. We can reuse the same control on the Find screen, the Admin screen, the "Products Like this" screen, and on the "Products you have chosen" screen. This code contains a lot of logic that is all in one place so it can be maintained easily, and it can be reused very simply too.
User Controls can be a very good thing. So you should use them when you feel like you can package up a group of existing controls, HTML etc. It makes them reusable, and much easier to maintain.
There is also the concept of custom controls - these are usually reimplementations of existing controls - you might have an ExtendedTextBox, for example, that validates the text as someone types it.
You can read more about both kinds of controls here
User controls are good for the same reasons that subroutines/functions/methods are good: code (and markup) re-use.
Like subroutines, controls can be a problem if they do things like modify global state, make lots of DB or other off-box calls that aren't always needed, introduce unavoidable synchronous blocking, etc. They can also add an unnecessary layer of complexity if they are never re-used.
I would use the controls that the VS IDE Toolbox provides as much as possible. I would only roll my own control if something that the environment supplied, didn't quite do what I wanted it to do.
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
I wanted to know what various guidelines state about the usage of this. Sometimes I use "this." to get the auto popup help versus to make any distinction of the code. I feel this is sorta bad style but can't say for certain.
What do various C# and .NET style guidelines state about trivial this usage?
(Editors please don't remove this post. This is a legitimate question because I am phrasing it as what style guidelines state about this and not opinion where style guidelines are formal guidelines, i.e that one can find on the net and are published.)
You can use control space in the editor to pull up the intellisense box. You should reserve using this explicitly to situations where not using it would cause confusion.
It makes more sense to use 'this' than to resort to a naming or prefix scheme in order to be less ambiguous. Since the point is usually to make code more readable using 'this' allows for clearer interpretation and less chance of bugs.
What is the benefit of writing meaningful css .class and #id names? Do screen readers speak to help the user understand the meaning and purpose of content inside the tags?
Generally-speaking, it's beneficial for the developer/designer only.
Again, as all your recent questions on semantics, the answer stays the same:
It all depends on the data-context of the entity in question.
If your element holds a meaningful field, it is useful to assign it a class (even if you do not want to apply CSS to it) just to easily define that particular field:
<span class="username">Andrew Moore</span>
Doing so has the following advantages:
It easily identifies the field's content in your code.
It increases maintainability.
It helps parsers and third-party applications to fetch this field's value.
Microformats are just a larger example of this. Simply put, they are a set of pre-defined elements and attributes that hold a particular set of data, meant to ease parsing by third-party tools.
Other answers are good, but I will focus on the scraping/third party tools aspect here.
Case 1 is spiders and crawling like search engines. If they parse your page and see something like id="username", they will be more likely to figure out some meaning in that than id="div-style-32". Granted, I'm not sure Google is doing this sort of thing now, but it could be if more people were better about it.
Case 2 is people writing scripts to pull down the HTML and process it in order to extract its content as data. Pretty much anyone who wants to do this can with any markup, its just a matter of how annoying it is. Cleaner and more well described markup allows the scraper script to more easily find the information it needs due to it's increased semantics.
This also includes things like browser extensions or Greasemonkey scripts that allow users to alter the behavior of the site. It will be easier to create these modifications with cleaner markup.
But if you don't want people scraping or modifying your site with client side extension, there is little you can do about from a technical standpoint. You can't stop it, you can only make it more of a pain in the ass. And the benefits of maintainability for the site developers are huge. So really, why not?
In short it makes all the different things you or others could do with your site easier to do.
You don't do it for the machines but for the humans.
If we only cared about machines we'd still be coding in assembly :)