When you provide only one side of the story you allow the listener to fill in the other half on their own. This can be a powerful story telling tool...
... but when you don't want to leave a situation open to interpretation you need to provide both sides of the story.
When learning how to do something new you find guides explaining the "Do's and Don'ts of [...
I prefer 'Sentence case' over 'Title Case' because sentence case respects the difference between proper nouns and the other words.
I always thought that it was customary in English.
In Spanish it is not, we use sentence case, like this traditional Argentine newspaper does.
This traditional USA newspaper uses Title Case instead.
These are language differences....
but I fell that users would like it better if the app had a consistent design across all platforms
Do a lot of your users carry around iPhones, Androids and Windows phones and use them interchangeably?
And if they did, they're likely power users already familiar with the different OS idiosyncrasies anyways.
Point being, from a user ...
My approach to this is completely style-guide oriented.
The online University of Oxford Style Guide states:
The general rule is not to use a capital letter unless it is absolutely required.
The Oxford Guide to Style states:
Capitalize the first letter of headings and captions.
So it appears Sentence Case is the way to go, event for captions.
The focus state should be more obvious than the hover state
A mouse over or :hover state is a more direct interaction (i.e. the user is controlling the mouse cursor directly over the button they want to click)
The :focus state, on the other hand, requires a separate scan of the entire page in order to determine which component is currently being targeted. ...
Aside from the case that has been made for improved readability, I also argue for sentence case it on the grounds that it's an easier rule to remember for people actually implementing (graphic designers, engineering, writers, etc.). Title case lends itself to all kinds of arbitrary decisions when implementers don't want to be bothered to look up whether "...
Dont's can be as important as Do's in UX
While design frameworks should focus on describing positive practices and principles (do's), it's important to provide guidance on avoiding common pitfalls, antipatterns, and errors.
Some best practices are simply easier to articulate in the negative than in the positive. For example, which of these is easier to ...
There's the term "same same but different" meaning certain things across the apps should be consistent like the branding and visuals while at the same time it should be consistent with patterns used on each native platform.
You should ask yourself is it likely that users will switch between platforms often or will they be switching between apps on the same ...
Honestly, as long as your :hover state & :focus state are very clearly showing exactly which item will have action the taken on it, I can't see any reason to style them separately. :focus is essentially a keyboard hover.
The previous answer is correct in saying that a :focus element should contain a box around it, but as long as the outline property isn'...
Create a consistent UI. The styles of the platforms come and go. You have no control over it. When the current trend fades, you'll have to redesign. You're better off building your own image/style guide.
You should use some bits of the platform's design guide (icons etc), but definitely give your app an unique and consistent look especially if it's blending ...
You could always use the standard 5 button full number intervals like you were previously but allow the selection of half intervals. Like so:
Example seen here (I have no affiliation): https://codepen.io/jamesbarnett/pen/vlpkh
This format will allow you to take up the same amount of space and not overclutter the component while still allowing half-step ...
Does it make sense to write principles, and maybe some sort of general design style guide which can be applied to all of them, and the future ones?
It probably does. Certain design principles and patterns will apply to just about any digital experience; only in rare cases does it make sense to maintain separate standards for everything. Think about it:
Title Case for Headings and Buttons
It's easier and faster for users if they can to identify the shapes of words.
"We recognize words from their word shape." also called the Bouma Shape.
Read more: http://en.wikipedia.org/wiki/Word_recognition
Bouma Shape: http://en.wikipedia.org/wiki/Word_recognition#Bouma_shape
A Few Examples
You're essentially asking how to design an pamphlet to interrupt someone's attention and get them to read something that they aren't interested in. The answer is that you shouldn't. It's poor UX.
If you want people to read a pamphlet, however there are a few things that you can do (outside of the design of the pamphlet) to increase that possibility:
It depends what you want to achieve.
There is some evidence to show that the use of capital letters slows the ability for people to scan content – it breaks the flow.
So if you want users to READ and not SCAN the buttons or the titles you should use "Title Case"
With regards to buttons, if you use all-caps, then it allows for perfect vertical centering of the text within the button. No need to worry about ascenders / descenders. However, if your text is longer then 2-3 words it can be difficult to read. This is where sentence-case works well.
What you call visual elements are really just the parts that are unique to one application vs. another. The logo, color scheme, and icons are most often unique elements that have to fit into, and often determine to an extent, the style of the website.
UI elements are just building blocks that can be used and which are expected to be well known to people ...
For Microsoft's take on the writing style guide for the German language you can take a look at the following link (page 20):
The closest thing I can think of to what you're looking for are Interface Guidelines.
A good example of this is Apple's iOS 7 Human Interface Guidelines, specifically the controls section. They have lots of pictures of UI elements with call outs, descriptions of how they are meant to be used, and defining characteristics.
iOS 7 Human ...
There's a couple of CSS frameworks for Material Design, not including Polymer:
Material Design for Bootstrap: http://fezvrasta.github.io/bootstrap-material-design/
There's also https://material.angularjs.org/#/ if you happen to be using AngularJS, but that might be a little bit heavy for your liking too.
The key message to communicate to the reader is not the do and it is not the don't either. It is the difference between the two.
Showing the two next to each other communicate this difference about as clearly as it can possibly be done. If you show them only one of the two, they will be left guessing what difference you actually had in mind.
It is also ...
If your buttons are bigger users will be able to select them faster which increases usability
This is actually a law! It was proven by Paul Fitts in 1954. Fitts's Law provides a mathematical model which can accurately predict the amount of time taken to move to and select a target. Although, originally developed for movement in the physical world, UX ...
Google has a wonderful visual style guide that applies across platforms:
Here's a style guide for an IBM conference, although it's more concerned with branding than software, it could serve as the ...
I have experience of three different tools for creating style guides:
The first style guide I implemented was built using Confluence. It was more a design pattern library, containing patterns and best practices for the most common UI design problems. Each pattern contained an example image, description how it works and why it should be used, and ...
I would go by asking the question... From a field scannability perspective, what's more identifiable in your data? The Labels or the Value?
The left details version places more emphasis on the Values vs the right details emphasizes the Labels.
For your example of "Who, When, Where", the values themselves are pretty much understandable without the labels. ...
I dont think this is specific to UX. This is actually a question of knowledge management. There is a whole ecosystem of people/products/services for this kind of thing.
Software like Wikis like Confluence, SharePoint, MadCap Flare, Salesforce Sites, Google Docs all are viable options. It depends on your security (and other) requirements.
This is another one of those questions where terminology (or how they are inconsistently applied) can make it really difficult to understand, so again in my answers to these types of questions I'll try to stick to the concepts/ideas and leave others to work out the semantics of it all.
Generally speaking, a style guide and/or a pattern library (you could ...
This depends on context. If this is a style guide (or guidelines for styling), see this: https://en.wikipedia.org/wiki/Style_guide
This article is also very useful:
This is also a good resource:
This is also a good useful guide:
Working on a styleguide now. It's in HTML, running on a local server. There are several reasons for rendering it on the web:
1. It's very easy to share, navigate and search.
2. You can see interactions and behaviors as they will appear to users.
3. Code snippets -- a styleguide isn't much use to developers, unless you provide the .css, .js and .htm files ...
I agree with Aviva Rosenstein that you have to design your deliverables just like you design your projects, by asking questions like:
Who's the target audience?
What are their needs?
What needs to be communicated?
What are their goals?
For me, I'm increasingly trying to influence our team of developers to adopt best practices/corporate standards. ...