I have the following problem:
I want to use images for my navigation, because I want to use a special font (Meta).
I know that images for navigation suck very much, so I am wondering what the best way to build such a navigation would be.
I have 2 main concerns:
Google findability.
Usability.
It is for my design portfolio so I am not overly concerned with screen readers (not much sense in my opinion, since it is all about designs in any case).
Is it better to use real images ( incl. alt tags) or should I just hide the text using a negative text-indent and use a css background image. Maybe there is even a third and better way.
Thanks.
Images with alt text will be fine for web spiders, but not ideal for usability (you can't search a page for alt text in most browsers). Negative text indents are searchable, but the highlight won't be visible and IMO that's actually worse.
The best solution is to use a web font instead of images. You can generate one from your desktop font easily with Font Squirrel.
Related
So I've been creating a custom responsive theme in Wordpress and I've hit a wall when it comes to image management. I'd like to style images in a way that wordpress doesn't seem to inherently support - I'm looking for something like this:
with the images added via the regular wordpress media management pane, and inserted into posts/pages. The images should be out of the flow of the content but accurately placed next to the correct headers/text blocks. Most importantly, the images ought to collapse into a column with the rest of the content at the correct media query breakpoints.
Here's what I've tried, from worst to best:
Hard coded images in template files
Obviously the worst option. Not portable, requires a lot of meddling, and would be almost impossible to align the images with the correct content. Also, no real way of making the images responsive with the content.
Use the default image styling and abandon the idea of pulling the images out of the regular flow
Non optimal, but it would allow anyone to change/edit images easily.
Remove images from the results of the_content(), then place and style them separate.
Portable, but has the same problems as #1 - difficult to align the images with content and keep responsiveness.
Use the featured image on pages that only require one image
Pretty good option for pages that need ONLY one image, but there is no easy way to make the featured image an arbitrary size/aspect ratio.
Use markup in the editor to correctly layout the images
Requires anyone editing the posts/pages to have some knowledge of the underlying theme. This seems to work the best, but it isn't portable (might break stuff on theme change).
While I've had the best results with this option, it seems sort of antithetical to using a cms/wysiwyg editor in the first place.
My question is whether or not the last option really is the best to get the result I want?
In the end, the answer was clearly custom fields, and none of the other options I listed. With the advanced custom fields plugin, it becomes a breeze to do what I wanted. You don't need the plugin, but it makes image management a whole lot easier, as it fully integrates the wordpress media library with the custom field (which you would have to do manually otherwise). With the plugin, custom fields meet all of my needs (responsiveness, portability, and ease of use for the technically challenged).
Say we have an overlay DHTML panel on a web page that contains two buttons in the top occupying whole width of the dialog, like this:
Text for Button 1 and Button 2 should be localized. Content of checkbox group is static and should not be localized.
There can be a big difference between button text width in different languages (~100% extra space in comparison with English version).
The question is which strategy to apply for sizing Button 1 and Button 2 depending on the length of the text content:
Make buttons fixed width and truncate text content with ellipsis.
Make buttons fixed width and wrap text content on the subsequent lines making buttons grow in height.
Make buttons fixed width but make them wide enough to host text in all languages without truncation or wrapping.
Make buttons dynamically adjust width and make panel grow horizontally with their size.
I am leaning towards using third or forth option according to the several UI localization best practices that were found:
Preparing the User Interface for Localization
Best Practices for Globalization and Localization
Globalization Step-by-Step - UI Considerations
Still we have some debate in the team discussing the best option and it would be interesting to hear concious outer voice of the community.
I am interested in the best approach for this specific case as well general guidelines for solving web UI sizing issues in regards of localization.
Thanks!
As you perhaps know, text shortened with ellipsis (or with a single dot) could be incomprehensible:
How compr. is th.?
You should seen a lot of this staff in mobile area (phones, tablets, etc.), such translations look ugly. OK, with lower screen resolutions you actually end up with no choice (unless you can create some auto-scrolling text). But in case of web interface you certainly have a choice.
Typically, there are two kind of solutions corresponding to your points #3 and #4. Personally, I am leaning to #4 - make buttons auto-sizable. This of course will result with inconsistently sized buttons, but there is little we can do about it.
If you cannot use solution #4 (i.e. UI Designer is strong opponent of this technique), you may modify solution #3 a bit. Basically, what I used in past projects was, I had buttons of fixed sizes and default size was capable to fit most of languages (except Polish and Russian of course), but I also had several CSS classes that defined wider buttons. When localizing into "too long" languages I simply used the most wide button class I could. If the text still didn't fit, then I asked the translators for shortening it (usually re-phrasing it and shorten the text with a single dot as a last resort).
However, please keep in mind that it increases localization costs. This is the reason I would not recommend this method.
As for solution #2, you will end up with ugly looking UI. You simply have no control over how browser will wrap a text, and you will have a lot of texts that go outside the button clipping rectangle (overlap it).
As for solution #1, using ellipsis is a bad idea for two reasons. First one is, ellipsis is not valid in many languages (this especially regards to Asian languages). The second one is, as I understand you want to do that automatically. In this case, you won't be able to measure strings - their actual, on screen size, written with a fall-back font. In case of web UI, you don't know whether user has particular font installed, so you will be guessing the size (OK, with Dojo you can theoretically measure it on the client side). This will of course result in overlapping text (if you decide on dynamic shortening over your chosen font) or totally incomprehensible text (if you decide on shortening after say 8 characters). I had a project which started to use static shortening, it was a total mess. Then we switch to dynamic and it is still not good enough.
To counter potential UI Designer argument that goes "we have no space for string expansion", I can only say that means that you designed the interface incorrectly for it is too crowded. This is the point where I18n goes hand in hand with UI design best practices: strive for simplicity (in UI design). The result would be easy to use and easy to localize application.
I have a site that requires Trade Gothic. I'm wondering if it's better practice to use #font-face or cufon with a font that looks similar to Trade Gothic or just go the image route. Obviously, using images will look better but what is better practice? For example, is replacing header titles with images like below bad?
<h2><span>title here</span></h2>
span { display:none }
h2 { background:url(image.jpg);display:block;height:x;width:y }
It depends on the strictness of your requirement and browser support within your target audience, especially if you want to support mobile devices.
If using a similar-looking font is good enough, the requirement may really be a nice-to-have feature, so anything that degrades gracefully should work. #font-face seems the easiest to implement (just CSS and font files) and it doesn't require Flash or JavaScript (good for mobile users). Google Web Fonts is a great resource or you may even be able to create your own web font using a generator like this one.
You'll have to decide what works best for the majority of your audience and weigh in how flexible the requirement is. If you use a JavaScript-based solution and the audience has it disabled, is that a deal-breaker? Image replacement is not inherently bad, but it can be tedious to maintain if you have much content to worry about (especially if it also changes often).
I use both.
I like to use Cufon for navigation and/or main heading elements, because I think it renders better (specifically in Windows).
For any sub-headers and other text, I use #font-face, so that users may select the text.
I'm currently replacing header images with #font face, as they can load quicker, and text is always more SEO friendly, however you must be careful when doing this as this increases http requests which can then take longer to load. Also there are some legal issue as to which fonts can be used for web.
However it is especially ideal when no other font will do.
FYI browser support for #font face has been available since IE 4, as far as I know.
Well, the most obvious advantage that #font-face and cufon have against the image replacement method that you mention is that they generate your text dynamically and you don't have to create an image for each text that you want to replace.
Take a look here:
https://stackoverflow.com/questions/692990/sifr-vs-cufon-vs-typeface-js
I'm working with Course Management System Moodle and in the admin the folder tree (which uses folder icons) displays for about a second the alt attribute given (In this case "Open Folder") then it hides and shows the image when the image is ready.
The system is kind of slow so I assume Firefox thinks at first that the images don't exist.
This is a problem because during that split second the layout stretches to fit the wider words making it look unprofessional in my opinion.
Is there a way I can hide this tag without having to remove the alt tags? (which would be labor intensive) maybe using JQUERY or CSS.
displays for about a second the alt attribute given (In this case "Open Folder") then it hides and shows the image when the image is ready.
Yes, that's what alt text is for: it provides a textual alternative for when the image isn't available — whether that's because there's an error, or images are turned off in the browser settings, or, in this case, the file just hasn't arrived yet.
Is alt text really what you want? Unless the image in question actually contains the words “Open Folder”, the above is inappropriate alt text. If we're talking about one of those little plus/minus icons that opens a tree, a better alt text would be ‘+’. “Open folder”, as a description of what the image does (as opposed to what it contains), would be better applied to the ‘title’ attribute used for tooltips.
Note that if you're using Quirks Mode and the image has a fixed size specified, Firefox will use a ‘broken image’ icon with the alt text overlaid and cropped inside, instead of the plain alt text on its own. This is to match IE's old behaviour. But you don't really want to use Quirks Mode, and in the common case where the fixed size is small, the cropping makes the alt text unreadable and useless.
This is a problem because during that split second the layout stretches to fit the wider words making it look unprofessional in my opinion.
I'd recommend: getting over it. That's how the web rolls, any page can move about a bit as it renders progressively. For images you should only ever see it happen once, then the image will be cached and will appear straight away. If it doesn't, there's something wrong with the cacheing setup.
Depending on what kind of layout you are talking about, you can perhaps fix that to not respond to the changing image size, too. For example if using a table, setting “table-layout: fixed” on the table and “width: (some number of)px” on the top row's image cell will make it stick to that width even if the text inside is smaller. Possibly causing the alt text to run over into the next cell though, mind.
If the images are part of the layout, I'd recommend moving them to CSS. You should also optimize your images wherever possible whether they are CSS or otherwise. You could also move your JavaScript files to the bottom of the page where possible as they block parallel downloads. In general, applying a lot of the techniques here would probably help.
If the images have to be a certain width, give them an explicit width.
What are some best practices on enabling a web application to support multiple resolutions? Specifically resolutions that are wide-screen vs. normal aspect ratio.
It doesn't seem like there is an easy answer - other than simply supporting a few fixed resolutions and using some absolute positioning to get the layout to work correctly.
This of course gets even more difficult to make it cross browser.
Does anyone have any good resources of this problem?
You can always try to use a liquid layout structure where the width of your elements are scaled proportionate to how wide their browser window is.
here is a good article explaining different layouts including liquid layout.
http://www.maxdesign.com.au/presentation/liquid/
PS. the above mentioned site (maxdesign.com.au) is using liquid layout itself, so try and change the size of your browser when reading the article.
One fast, simple, fairly robust way is to use a framework like Blueprint or 960gs to lay out the site. They're browser-independent so you don't need to worry about that, and they make most column layouts pretty easy.
They both work on the idea of creating a fixed-size container somewhere between 900 and 1000 pixels wide for your content. Most people run in at least 1024x768 nowadays. If you need more width than that for your content, you're probably doing it wrong.
The one area where ~960px might not work is mobile phones... but that's what mobile stylesheets are for, right?
In Opera and Safari (esp. their mobile versions) you can use CSS3 media queries, which let you declare completely different styles for different screen resolutions.
This can be emulated in other browsers using Javascript – Alistapart: Switchy McLayout
You can use percentages to set width and heights also, but this is also difficult sometimes.
You have two options here:
Fixed Width Layout
Flow Layout
Both have benefits and drawbacks, and in the end, it's a design decision as to which is the best choice.