In carefully edited text, the choice to include the article depends on the meaning. Examples:
I saw a newt yesterday, dark with blue spots. Can anybody help identify it?
— Article not included: the reader guesses that the linked page is about newts in general.
I saw a newt yesterday, dark with blue spots. Can anybody help identify it?
Usually an article need not be a part of your link.
Except in the cases when it makes a difference in meaning. Usually it will be a definite article, like "The Times", "El Salvador", "Al Jazeera".
Sometimes you can see Portugal city Porto spelled as O Porto. This is because porto means just "port" in Portuguese, so the city is not just Port, but "The Port"....
As the search bots don't give importance for this stop words (the, a, an...) you don't need to hyperlink them.
What's Stop Words on Wikipedia:
In computing, stop words are words which are filtered out before processing of natural language data (text). Stop words are generally the most common words in a language; there is no single universal list of stop ...
Since giving system feedback to the user that shows something is happening is essential, otherwise they will think something is broken, I don’t immediately see a reason for this.
Here is a depiction if the user experience during loading:
There might be a dev reason or simply a call made by some manager or developer, but we will never know.
I would encourage including the article: not for SEO, only partially for grammar, but to increase accessibility .... if it's a mouse-based user-base or mobile app where finger-actions are most important. Larger targets are easier to click.
However, for screen-readers, I would encourage not only not omitting the article, but (when possible) allow links to ...
The UX answer would be to provide the best experience for your customers.
If full-width is your solution then you will need to create and implement designs for multiple break points.
To answer your question directly. No.
980px is useful as approximation for a desktop users. It works on designs for 1024 and above. Example: a design with side margins.
You can simply add the label of the input for context, for example "Clear First name". This is particularly useful if this type of button exists on multiple fields on the page, otherwise it could be unclear what field this button is clearing, especially if users navigate by button or show a list of form items.
Just two unrelated notes on the markup you are ...
Your concerns are valid, I'll highly recommend including the month. Some reasons:
Users need just a brief moment of distraction to forget what they are thinking and as a industry rule it's better to avoid making them think and recheck unnecessarily.
There's not an easy way to deduce in what month we are based just on a day or its number.
To avoid the ...
The type of confirmation you choose has many factors that may include matching the pattern that’s currently available in your system, considering systems the user might be interacting with in conjunction with your application, and the technical viability of both your user interface layer as well as the time/skill of your team. But just purely from a ...
I think this is part of WCAG 2.0 requirement to provide minimum contrast ratio guidelines. Success criterion 1.4.3 and 1.4.6 mentions providing a style switcher to high contrast for the users with visual impairments.
More info can be found here: https://...
This is commonly called "alphabetical section index".
In terms of affordances, the concept is akin to the cardboard tabbed index dividers featured on paper indexes and directories.
This usability component has also been discussed in this community under the description "small alphabetical index" here.
A quick search results in several implementations: 1, ...
As Stacy H and Garik have already mentioned, reproducing a toggle-ish button is what you can do in this sense, in case you need visualization this is how it potentially could look like with the different states
You can make it more obvious that more than one selection is allowed by changing "Book" to "Select" and then putting the selected tiles in a "selected" state -- maybe the black button becomes a vivid color, the tile has a halo, and a checkmark appears next to the word "Select". You can then add a "Check out" or "Book Services" button in a prominent place ...
It sounds like each row holds "a few buttons" and you're going to need the right amount of space to make sure that the user doesn't accidentally click the wrong button by mistake, especially if they'll be tapping a touch screen.
White space is good for preventing cognitive overload, but sometimes data density is the greater UX need. The important part is ...
You should try to avoid these discussions, they will not result in anything valuable. Instead, either make it a user choice by providing a switch, or test it with real users.
As with most such discussions in UX, context is utterly important, and the best course of action is a test: Give realistic tasks to target users, who will need to use your design to ...
I really recommend reading this article from Uxplanet: Rounded or Sharp-Corner Buttons?
You can take these points home:
-Squared Sharp designs are usually viewed as firm/serious/uniformed
-Rounded designs are viewed as friendly and harmless.
You cannot really identify a pattern from the examples you provided above. Facebook uses sharp corners for Login, ...
Yes, users on web also need help. It is good practice to make it an option,
First of all, I think you need to work with your copy (which you probably will see if you test your design).
As a user I have many questions:
* What am I signing up for
* What am I getting (value)
I would test it with 2-5 users. Then I would come up with solutions to ...
There are three very different sections to the screen you shared. One has to do with a schedule at a glance for 7 days, one is responding to what could be notifications/requests for appointments and one is for actions that I need to taken my current job or just completed ones.
Feels like these should all be separate pages:
Calendar View to see your whole ...
Devices in the wild are too diverse for a single size to work well for everything.
Design for the widest monitor you'd expect, likely around 4096.
Create differently sized variants for smaller monitors. Could be via rescaling or cropping or other means.
IMHO, I don't think 980 is a good rule of thumb for anything fullwidth on desktop or tablet anymore, especially because of "retina" displays. If I had to choose one resolution to rule them all, I'd probably go 1440 or 1920, but you're still going to be shooting in the dark there and adversely affecting users with poor connections.
Some of this depends on ...
I think you might need to look at content marketing strategies for this. Maybe design some landing pages and direct traffic to it. But you could also think about how this website shows it's child websites, stack exchange has it's global nav and the child websites sit inside of them.
This is a design review, I believe that is not the right type of question that people expect to find here.
Anyway, if you came here with theses you have a reason and you did not find help anywhere and I will help you with some UX tips.
At first, I do not see a big UX difference in your templates. Everyone looks the same.
From my viewpoint I suggest you to ...
It could be because, back in 2001 when Rob Chandanais of BlueRobot came up with the pure CSS version of this layout, our monitors were much smaller and resolution wasn't as high. Websites had an infinite amount of vertical space, unless you wanted horizontal scrolling. Therefore you could have a lot more navigational items in the menu. Also, it was arguably ...
Generally I think that every element or component should satisfy the principle of affordance. Meaning it should be obvious what they can do and how they should be used on the first sighting.
In your case you should come up with a style for your input fields that makes it obvious that they are input fields. My suggestion is to have a look at design guides ...
Depending how much you want to highlight the relationship you could use one of several approaches:
Do like stack exchange: add a link to the child site on the parent and vice-versa.
On the parent site: Add a section "built with our platform / facilitated by us / our events" and showcase / link to some / all the events, with a link to the child site. Or just ...
I like the clarity you show in the bottom picture, but that’s only my opinion...
All to easy for some users to make an error with months... lots of checks are written with the wrong month as it changes...
I do not have an example, but some thoughts about such a toggle:
If you use a WCAG 2.0 conform contrast in the first place the toggle wouldn't be necessary. And there are more benefits in that: the readability of your site will be enhanced for all users.
Having a toggle might make some user feel handicapped because they need to change the settings of the ...
Trying to use a pixel width for a standard size has been a losing battle for years and no web developer or designer should have that as a goal. You do not know, and cannot reliably determine, the size of anyone's display size. So don't do that.
The best response I've ever read about this question is, start with the smallest possible display width--which is ...
It is not as common1 to encounter native desktop applications in which the entire application scrolls. Sure, there may often be regions on a page, or a particular page or section that scrolls, but the application's layout is typically static, and this is what users tend to expect.
Historically2, this has lead to a designer having to make ...