SRP(PDF version; HTML version) states that
There should never be more than one reason for a class to change
When you take a look at Outlook, Calendar Event window, it has "Save and Close" button.
So when the functionalities of either or both Save or Close changes, that button should change. It obviously violates SRP.
This functionality both saves time and convinient since that is what most of users expect to do when they save an appoint on a calendar.
But now, my question is, when else do you violate SRP other than when the feature need to be usuable in Outlook?
SRP does not apply to UIs. Keep in mind that even though the button is called "Save and Close" there can undoubtedly be two separate methods or types to handle the saving and closing functionality. The button simply ties those two separate pieces of functionality together.
If you feel the need to violate SRP then you need to re-evaluate your approach. Any SRP violation can be refactored into a new method or type that exposes the composite functionality by means of composition of the two pieces.
Related
I am being asked to put checkboxes on a webpage that perform no resolution, in that they simply exist to be checked in the form of a checklist that could be printed. There would be no form submission, no buttons, no popups or collapses, and no actions resulting in the checking of the boxes.
I believe this would be against the grain for UX and potentially against accessibility rules. Are there any rules I can reference in the WCAG guidelines that would back me up?
A couple of things to consider:
If the checkboxes perform a function in that they allow the user to check off which items are completed, then they are there for a reason but it's a question of whether their purpose has been clearly communicated.
From what you describe, non-accessibility users would be getting the same non-functioning checkboxes that accessibility users get, so accessibility is less of a consideration here than UX design. Accessibility is concerned with providing an equivalent user experience and conveying the same information for assistive technology users as for non-AT users, so quoting a WCAG guideline won't really help if the design problem affects both AT and non-AT users.
With that in mind, the WCAG guideline that seems most relevant to me is 1.3.1 - Info and relationships. This guideline deals with preserving the relationship between page information and the semantic structure or layout of a page, so that the way a page is structured (including the components used) doesn't convey different things to AT and non-AT users.
A common failure of WCAG 1.3.1 would be something like using headings for presentational purposes, but it can apply to any component which has a semantic meaning that is different from the presentational meaning. In your case, using checkboxes as a presentational device could fall under that type of failure. See here: https://www.w3.org/WAI/WCAG21/Techniques/failures/F43
The situation is a bit unclear. The checkboxes are there to be checked, but there is no action that could result in them being checked. That seems to be a contradiction.
In any case, I believe it causes no accessibility issue to include checkboxes on a web page, regardless of whether they are in a submittable form. There could be good reasons to do so. For example, if there are 10 checkboxes and the instruction tells the user to check no more than 4 of them, a script could enforce that requirement. Whether the purpose is to let the user print the page, or save it as a PDF file, or send a PDF version by email, or think about a topic, checkable checkboxes can be useful, and I know of no basis for an inference that they must be submittable to a server.
It's possible add extra states to defaults states of a widget ?.
For example, working with styles in tk (ttk) some times the options to configurate a widget are very limited. However, using the command ttk::style map and (if possible) defining extra states, would be easy to configurate it.
The low level state management engine maps the states to bits of an integer. The full list of supported states is (this is information extracted straight from the C code; this is utterly the ground truth):
active — Mouse cursor is over widget or element
disabled — Widget is disabled
focus — Widget has keyboard focus
pressed — Pressed or “armed”
selected — “on”, “true”, “current”, etc.
background — Top-level window lost focus (Mac, Win “inactive”)
alternate — Widget-specific alternate display style
invalid — Bad value
readonly — Editing/modification disabled
hover — Mouse cursor is over widget
reserved1 — Reserved for future extension
reserved2 — Reserved for future extension
reserved3 — Reserved for future extension
user3 — User-definable state
user2 — User-definable state
user1 — User-definable state
Looking through that list, I'd guess that particularly user1, user2 and user3 are open to use for your extra states. Defining more than that requires custom changes to the C code, but you have three right there to be going on with.
I guess at a pinch, reserved1…reserved3 could also be used. I shudder to think of how complex a UI must be to need that many different independent state descriptors, but they're there and I really doubt that Ttk will make much use of them any time soon. (If you're making a lot of use of this sort of thing, do drop a line to the developers of Tk to let them know about it; it helps persuade people to not “optimise” away this stuff and particularly good uses might lead to a state bit becoming officially named.)
Please don't reinvent the meaning of any existing state flag though. Everything is confusing enough without that!
As far as I understand, not rendering the HTML for an element at all, or adding display:none, seem to have exactly the same behavior: both make the element disappear and not interact with the HTML.
I am trying to disable and hide a checkbox. So the total amount of HTML is small; I can't imagine performance could be an issue.
As far as writing server code goes, the coding work is about the same.
Given these two options, is one better practice than the other? Or does it not matter which I use at all?
As far as I understand, not rendering the HTML for an element at all, or adding display:none, seem to have exactly the same behavior: both make the element disappear and not interact with the HTML.
No, these two options don’t have "exactly the same behavior".
If you hide an element with CSS (display:none), it will still be rendered for
user agents that don’t support CSS (e.g., text browsers), and
user agents that overwrite your CSS (e.g., user style sheets).
So if you don’t need it, don’t include it.
If, for whatever reason, you have to include the element, but it’s not relevant for your document/users (no matter in which presentation), then use the hidden attribute. By using this attribute, you give the information on the HTML level, hence CSS support is not needed/relevant.
You might want to use display:none in addition (this is what many CSS supporting user agents do anyway, but it’s useful for CSS-capable user agents that don’t support the hidden attribute).
You could also use the aria-hidden state in addition, which could be useful for user agents that support WAI-ARIA but not the hidden attribute.
I mean do you need that checkbox? If not then .hide() is just brushing things under the carpet. You are making your HTML cluttered as well as your CSS. However, if it needs to be there then sure, but if you can do without the checkbox then I would not have it in the HTML.
Keep it simple and readable.
The only positive thing I see in hiding it is in the case where you might want to add it back in later as a result of a button being clicked or something else activating it in the page. Otherwise it is just making your code needlessly longer.
For such a tiny scenario the result would be practically the same. But hiding the controls with CSS is IMO not something that you want to make a habit of.
It is always a good idea to make both the code and its output efficient to the point that is practical. So if it's easy for you to not include some controls in the output by adding a little condition everything can be managed tidily, try to do so. Of course this would not extend to the part of your code that receives input, because there you should always be ready to handle any arbitrary data (at least for a public app).
On the other hand, in some cases the code that produces the output is hard to modify; in particular, giving it the capability to determine what to do could involve doing damage in the form of following bad practices: perhaps add a global variable, or else modify/override several functions so that the condition can be transferred through. It's not unreasonable in that case to just add a little CSS in order to again, achieve the solution in a short and localized manner.
It's also interesting to note that in some cases the decision can turn out to be based on hard external factors. For example, a pretty basic mechanism of detecting spambots is to include a field that appears no different in HTML than the others but is made invisible with CSS. In this situation a spambot might fill in the invisible field and thus give itself away.
The confusion point here is this: Why would you ever use display: none instead of simply not render something?
To which the answer is: because you're doing it client side!
"display: none" is better practice when you're doing client side manipulations where the element might need to disappear or reappear without an additional trip to the server. In that case, it is still part of the logical structure of the page and easier to access and manipulate it than remove (and then store in memory in Javascript) and insert it.
However if you're using a server-side heavy framework and always have the liberty of not rendering it, yes, display:none is rather pointless.
Go with "display:none" if the client has to do the work, and manage its relation to the DOM
Go with not rendering it if every time the rendered/not rendered decision changes, the server is generating fresh (and fairly immutable) HTML each time.
I'm not a fan of adding markup to your HTML that cannot be seen and serves no purpose. You didn't provide a single benefit of doing that in your question and so the simple answer is: If you don't need a checkbox to be part of the page, then don't include it in your markup.
I suspect that a hidden checkbox will not add any noticeable time to the download or work by the server. So I agree it's not really a consideration. However, many pages do have extra content (comments, viewstate, etc.) and it can all add up. So anyone with the attitude that they will go ahead and add content that is not needed and never seen by the user, I would expect them to create pages that are noticeably slower overall.
Now, you haven't provided any information about why you might want to include markup that is not needed. Although you said nothing about client script, the one case where I might leave elements in a page that are hidden is when I'm writing client script to remove them. In this case, I may hide() it and leave in the markup. One reason for that is that I could easily show it again if needed.
That's my answer, but I think you'd get a much better answer if you described what considerations you had for including markup on the page that no one will see. Surely, it must offer some benefit that you haven't disclosed or you would have no reason to do it.
I'm always feel the disabled attribute for HTML <input> and all is twisting my brain. Why choose a negated attribute name, isn't enabled more intuitive?
Just compare:
enabled=advancedUser
disabled=not(advancedUser)
enabled=not(locked)
disabled=locked
enabled=advancedUser and not(locked)
disabled=not(advancedUser) or locked
disabled=not(advancedUser and not(locked))
The fundamental reason behind this is that it was a later addition to the HTML input fields, and needed to be that way to maintain backward compatibility with existing web pages.
When the <input> tag was originally defined, its functionality was extremely limited. It did not have disabled or readonly attributes, nor many of the other properties we take for granted today.
These were all added later, but by the time they were added, many web sites were already using <input> fields, so the ability to disable it had to work without affecting existing code that didn't use it. Therefore the default state had to be enabled.
It also had to be a boolean flag, which is why it is disabled rather than enabled=true. The latter would have been a key-value pair attribute. This wouldn't have been a good choice.
Consider the following:
enabled=false
enabled=0
enabled=FALSE
enabled=no
enabled=disabled
enabled=flase
etc...
The browser would have had to be able to cope with a huge number of possible values. Making it a boolean flag simplifies things enormously. It makes the spec easier to understand, both for the web site developer and the browser developer.
The other thing to bear in mind is that the time when this property was added to HTML was in the middle of the so-called 'browser wars'. Many features were being added to the competing web browsers, in a hurry and without the benefit of formal specs, and many features were added which we can indeed look back on and wish it were slightly different.
I don't believe this is one of those features: the disabled flag is perfectly logical really if you stop and think about it. But it's quite possible that it may have been better designed if the browser developers had been co-operating a bit more back then.
But whatever the case, the situation today is that this is what we have. The HTML spec may be evolving, but existing features such as this are not going to change now.
I have a query In our application we have lots of HTML tags. During development many tags were not given any id because of no requirement.Now the QA team wants to automate the test cases using QTP. In most of the cases this tool doesn't recognizes because it does not find ids for most of the HTML tags.Now we are asked to add ids to all the HTML tags.
I want to know if there will be any effect adding id attribute to these tags. Even positive impact are welcome
I do not think there will be any either positive or negative effect : maybe the size of the HTML page will increase a bit, but probably not that much.
Still, are you sure you need to put "id" attributes on every HTML tag of your pages ? Wouldn't only a few of those be enough ? Like on form fields, on links, on error-messages ; and that's probably about it ?
One thing you must take care, though, is that "id", as in "identifers", must be unique ; which implies it might be good, before starting adding them, to define some kind of "id-policy", to say, for instance, that "ids for elements of that kind should be named that way".
And, for your next projects : have developpers add those when theyr're developping ;-)
(And following the policy, of course)
Now that I'm thinking about it : a positive effect might be that it'll be easier to write Javascript code interacting with your HTML document -- but that'll be true for next projects or evolutions for this one, when those id are already present in the HTML at the time developpers put the JS code in place...
Since there are no QTP related answers yet.
GUI recognition in QTP is object-oriented. In order to identify an object QTP needs a unique combination of object's properties, and checking them better to be as fast as possible - that is why HTML ID would be ideal.
Now, where it is especially critical - for objects that do not have other unique identifiers. The most typical example - html tables. Their contents is dynamic, their number on the page may vary. By adding HTML ID you allow recognition mechanism get straight to the right table.
Objects with other unique properties can be recognized well without HTML ID. For example, if you have a single "submit" link on the page QTP will successfully recognize it by inner text.
So the context-specific answer: don't start adding ids to every single tag. Ask automation guys to prepare a list of objects they have problem with. And add ids to those objects.
PS. It also depends on automation programming skills. There are descriptive programming and dynamic recognition methods. They allow retrieving the right objects even without ids provided.
As Albert said, QTP doesn't rely solely on elements' id, in fact due to the fact that many web applications generate different ids for each session, (as far as I remember) the id property isn't part of the default description for most web test objects.
QTP is pretty good at recognizing most simple web controls and if you're facing problems it may be the case that a Web Extensibility project will help you bridge the gap between the semantics of your web application and the raw HTML it is created in. If a complex control is recognized by QTP as a WebElement (which is actually the div that contains the span that drives the code) you will understandably have object recognition problems since there are many divs on the page but probably many less complex controls.
If you are talking about side-effects - NO. Adding ids won't cause any problems (apart from taking up some extra bytes of course)
If you really have the need to add ids, go ahead and add them.
http://www.w3.org/TR/html4/struct/links.html#anchors-with-id says: The id and name attributes share the same name space. This means that they cannot both define an anchor with the same name in the same document. It is permissible to use both attributes to specify an element's unique identifier for the following elements: A, APPLET, FORM, FRAME, IFRAME, IMG, and MAP. When both attributes are used on a single element, their values must be identical.