Related
What if I have a captcha that displays a series of English characters. Will people who don't speak English have trouble interpreting and/or typing these characters? If this is the case then what is the best solution for an internationalized captcha?
Since 99% of the URLs are in regular ASCII, I don't think you will have a problem..after all how would they get to Google or Yahoo if they couldn't type the URL
That said I have on occasion run across Chinese characters used in captchas
Image-based CAPTCHA has two main advantages over text-based CAPTCHA:
International
Harder to solve algorithmically (see PWNtcha - captcha decoder)
There are several flavors, such as:
Classification: see Captcha The Dog, KittenAuth, Microsoft Asirra
3D projection: see 3D images: A human way to create Captchas and 3D-based Captchas become reality
Detection: see Image-Based CAPTCHA from Confident Technologies and Pic-Capture
Rotation: see A Dynamic, User-Friendly Captcha With Pictures
Puzzle: see Key Captcha
It would be a problem for users using their native, non-Latin keyboard layout, for example Russians and Greeks. They would be forced to switch keyboard layout just to fill security question.
Another thing is an ability to even recognize the words - somebody who doesn't speak English could have huge problems with getting word right. Even I sometimes do (for less popular words), although I am quite proficient...
In other words, don't do this mistake, your application should be easy to use for all users.
It's definitely a concern. Dictionary-based CAPTCHAs should ideally adapt to the user's language preferences and ask them to recognize words that match their language preferences and by extension the character set they are most familiar with.
But in the absence of such internationalization, I would say that numerals and mathematical expressions are the most universal solution, and for word-based CAPTCHAs a random series of ASCII characters (which being random would be culture-neutral) would be the most accessible as pretty much any user around the world has the ability to enter these characters even if some have to switch their input method.
Now where it really gets tricky is providing accessibility alternatives for visually impaired users. Making a univeral audio CAPTCHA seems pretty much impossible (you could consider a set of universally-recognized sounds instead of spoken words, but I doubt this would provide sufficient security). And internationalized (multilingual) spoken word generation is far from trivial.
No, because English captchas are ASCII -- ASCII is always available, even if people have a Japanese, Chinese, or Russian keyboard. So this should not be a problem! And image based captchas only require the person to read the letter - and that should be possible for anybody on the web who can see, as SQLMenace pointed out.
The other way around is a problem though.
Google's reCaptcha has a little icon where the user can get a different captcha if for some reason the captcha is not readable or contains foreign characters.
I would recommend that you use Google's reCaptcha, rather than implementing it yourself.
Added Benefit:
Google's reCaptcha is also available for other languages btw. http://www.google.com/recaptcha/faq
which makes it possible for you to internationalize the captcha for the user's default locale.
EDIT:
There is a work-around for Google's reCaptcha to work with flash!
Check here:
http://groups.google.com/group/recaptcha/browse_thread/thread/e22d7e3c91bcc9db
Sure they are a problem. Would a Russian captcha be a problem for you? What about a Chinese one?
The URLs are indeed ASCII, but that is only relevant for geeks.
Regular people go to Google, type some text in their own language, and then click on one of the answers. Then never get to type an URL.
Yes, this could represent a problem to a small percentage of users. Is it a large enough problem to take into consideration when building the UI for your site to better the UX? That's up to you. If it were up to me, probably not.
To help you in the right direction though, I would use Google' reCAPTCHA. It serves a great cause and works like a charm. There's also a great API where you can customize the language that it displays. You could use PHP to detect their country and write some code to change the settings to display in their native language.
Here's a sample of changing reCATCHA's language. "fr" is french!
<script type="text/javascript">
var RecaptchaOptions = {
lang : 'fr',
};
</script>
Google reCATPCHA's API:
http://code.google.com/apis/recaptcha/docs/customization.html#i18n
I believe that the 24 letters that constitute the English alphabet correspond in most 90% of the world. We have Chinese, Japanese, Cyrillic and Arabic users however all of them have the possibility of switching to an English keyboard within their operating systems.
We have no diacritics in English which makes everything a lot easier and our system more easily adaptable all over the world. Everyone types ASCII but they are able to switch to their own zone-specific/language-specific characters.
Have we finally got to the point where we assume CSS2, and hope for CSS3?
(Not looking for discussion, if the answer is "yes, you idiot", go for it...)
You should always take into consideration users who
A. use screen readers and text-only browsers
B. are on mobile devices
C. are not human (i.e. search engine spiders)
By having a good separation of content and style, you should be able to address each of these with ease. As far as users who have CSS disabled, in this day and age, I don't think a designer should concern themselves over it too much. It's certainly not worth spending a significant amount of time and resources on.
What is your target audience and what is your cost for supporting (or not supporting) certain clients?
In addition to the fine points made by pst and ttreat31, I'll add that using semantic markup will generally let your document be readable with CSS disabled (i.e. using the browser's default CSS).
There may be a few quirks (forms come to mind), but generally I find with my own pages, they are plenty readable.
You, and your business, will probably survive if you require CSS. But you'll probably do better if you DON'T require it.
By catering for non-CSS cases, you'll write better markup, with better-structured content. You'll mitigate cross-browser problems, and develop a more robust API. Search engines will be able to parse and 'understand' your content that much better.
Allowing for 'no CSS' is much more about the philosophies relating to web standards and good coding practises than it is actually about the common final rendering.
I don't take any effort to help users who disable CSS or javascript. If I worked on a site which counted on attracting new customers and had lots of first time hits, then I would probably try and give non-javascript users a scaled down set of features. But I would never bother with users who disable CSS. I think that is probably a very small minority.
I often surf in the terminal using links or lynx when my computer is overloaded and I just can't have Firefox, Java, and some Flash applications taking half of my RAM. Text-only browsers don't have advanced CSS or Javascript support.
Many server administrators might do similar thing as most servers are headless, and some administrator might be too lazy to open their other laptop just for a quick browse. People using screenreaders usually have similar view as text-only browser, except it's now read aurally instead of text-only.
When using text browsers, I wouldn't expect any fancies colors or tables, usually I just need to have some quick information. So, IMO, you should at least make all the page's essential information available as plain HTML.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I want to protect only certain numbers that are displayed after each request. There are about 30 such numbers. I was planning to have images generated in the place of those numerbers, but if the image is not warped as with captcha, wont scripts be able to decipher the number anyway? Also, how much of a performance hit would loading images be vs text?
The only way to make sure bad-guys don't get your data is not to share it with anyone. Any other solution is essentially entering an arms race with the screen-scrapers. At one point or another, one of you will find the arms-race too costly to continue. If the data you are sharing has any perceptible value, then probably the screen-scrapers will be very determined.
It's not possible.
You use javascript and encrypt the page, using document.write() calls after decrypting. I either scrape from the browser's display or feed the page through a JS engine to get the output.
You use Flash. I can poke into the flash file and get the values. You encrypt them in the flash and I can just run it then grab the output from the interpreter's display as a sequence of images.
You use images and I can just feed them through an OCR.
You're in an arms race. What you need to do is make your information so useful and your pages so easy to use that you become the authority source. It's also handy to change your output formats regularly to keep up, but screen scrapers can handle that unless you make fairly radical changes. Radical changes drive users away because the page is continually unfamiliar to them.
Your image solution wont' help much, and images are far less efficient. A number is usually only a few bytes long in HTML encoding. Images start at a few hundred bytes and expand to a 1k or more depending on how large you want. Images also will not render in the font the user has selected for their browser window, and are useless to people who use assisted computing devices (visually impaired people).
Apart from the images, you could display the numbers using JavaScript or flash.
You could also use CSS to position individual digits using various combinations of absolute or relative positions.
You could also use JavaScript to help you create these DIV.
The point is just to obfuscate enough that it becomes really hard.
One more solution is to use images of segments or single dots and re-construct the images of the digits using CSS, a bit like a dot-matrix display.
You could litter the source of the page with these absolutely positioned DIVs and again make it more difficult to reconstruct by creating them dynamically.
At any rate, you can't stop a determined scraper from getting to the data: it doesn't take a lot to automate a web browser and take screenshots that can be fed to an OCR.
There is nothing anyone from paying someone pennies to get the data manually anyway.
The point is: how determined are your opponents (user?).
It's a bit like the software protection business: making things hard enough that you would deter casual 'pirates' is not too hard, and it's a fairly good approach in general.
However, if there is much value in the data you present, there is nothing you can really do to protect it.
All you can do it make it hard enough so that casual 'thieves' will prefer to continue paying for your services rather than circumvent it.
Javascript would probably be the easiest to implement, but you could get really creative and have large blocks of numbers with certain ones being viewable by placing layers on top of the invalid numbers, blending the wrong numbers into the background, or making them invisible via css and semi-randomly generated class names.
I can't believe I'm promoting a common malware scripting tactic, but...
You could encode the numbers as encoded Javascript that gets rendered at runtime.
Generate an image containing those numbers and display the image. :-)
I think you guys are being too reactive with these solutions. Javascript, Capcha, even litigation and the DMCA process don't address the complex adaptive nature of web scraping and data theft. Don't you think the "ideal" solution to prevent malicious bots and website scraping would be something working in a real-time proactive mitigation strategy? Very similar to a Content Protection Network. Just say'n.
Examples:
IBM - IBM ISS Data Security Services
DISTIL - www.distil.it
Can you provide a little more detail on what it is you're doing? Certainly there's a performance hit to create an image instead of dumping out the text of a number, but how often would you be doing this per day?
Using JavaScript is the same as using text. It's trivial to reverse engineer.
Use animated numbers using flash. It may not be fool proof but it would make it harder to crack.
What about posting a lot of dummy numbers and showing the right ones with external CSS? Just as long the scraper doesn't start to parse the external CSS.
Don't output the numbers, i.e. prefix
echo $secretNumber;
with //.
For all those that recommend using Javascript, or CSS to obfuscate the numbers, well there's probably a way around it. Firefox has a plugin called abduction. Basically what it does is saves the page to a file as an image. You could probably modify this plugin to save the image, and then analyze the image to find out the secret number that is trying to be hidden.
Basically, if there's enough incentive behind scraping these numbers from the page, then it will be done. Otherwise, just post a regular number, and make it easier on your users so they won't have to worry so much about not being able to copy and paste the number, or other such problems the result from this trickery.
just do something unexpected and weird (different every time) w/ CSS box model. Force them to actually use a browser backed screenscraper.
I don't think this is possible, you can make their job harder (use images as some suggested here) but this is all you can do, you can't stop a determined person from getting the data, if you don't want them to scrape your data, don't publish it, as simple as that ...
Assuming these numbers are updated often (if they aren't then protecting them is completely moot as a human can just transcribe them by hand) you can limit automated scraping via throttling. An automated script would have to hit your site often to check for updates, if you can limit these checks you win, without resorting to obfuscation.
For pointers on throttling see this question.
Update:
I deleted my motivation because it seems to distract readers. This is not about "why don't you make your window smaller". See the screenshots and you will see obstructed text because of fixed width. See my reference to "em/ex" notation in CSS. I would like to have a real discussion here. Thank you.
Now I would like to ask real experts on this topic -- I'm not a web designer -- why fixed width layout are still that popular and if there are really good reasons for it. (you are welcome to point out reasons against it as well.)
Is it too hard to design your layout relatively (from start on)? It seems some people even forgot how to do it.
Do you have real reasons like readability and just don't know how to deal with it correctly? Here I'm referring to pieces of wisdom, like it's harder to read longer lines (that's why newspapers use columns) -- but then, width should be given using em and ex.
Are you forced by some old guidelines? In the dark old age of HTML, people did a lot of things wrong; now everybody finally uses CSS, but perhaps this one just sticked.
Or are you like me, wondering why everybody is doing it "wrong"?
To illustrate the issue, I want to give screenshots of negative examples first:
StackOverflow (here I can't even see what would make it any hard to fix it)
Filmstarts (a german website which renders itself unreadable-if I don't take a reading-glass with me)
And here is a positive example. It looks like a typical fixed with site (even with transparent borders), but it is not:
Website on Wiki software -- associated Forums
What do you think?
Update: Related questions: this one and that one.
And here, as expected, comes the usual canard: “long lines are too hard to read”.
[Citation needed], folks.
See http://webusability.com/article_line_length_12_2002.htm for a summary of actual research in this area. A number of these, plus http://psychology.wichita.edu/surl/usabilitynews/72/LineLength.asp, find that although users express a preference for moderate line lengths, reading speeds do not sharply drop off with ‘long’ lines; in fact many show increased speeds with the longer settings.
As long as it's not ridiculously long, and taking care to use a decent amount of leading, long lines are not generally a real issue at today's typical browser widths and default font sizes. (If you're one of those designers that loves to use teeny-tiny type for everything, it could be an issue, but then you're already making it impossible to read with the flyspeck text. Stop it!)
So as it's only an option of user preference that prefers medium-short lines, let us users decide how much screen space we want to give the web site to get our work done. We're the ones best-equipped to know. If you decide you know definitively best you're likely to waste space, or, if you guessed too long, make us scroll back and forth sideways to read the text — and that really is a readability nightmare.
If you want to protect us from ourselves, you can compromise by specifying a min-width and max-width in ‘em’ units so that the page is responsive to liquid layout, but doesn't get stretched to extremes.
But otherwise, the best reason to design fixed-width is indeed that it is easier, especially for someone with a fixed-2D-grid view of the world and static visual-design tools like Photoshop.
It's already a pain to make a website that renders correctly across all popular browsers; if you also want it to render correctly at all text sizes, it's quite a lot of work. A lot of web developers design their sites for the default font size and try to support fonts that are either a little bit larger or a little bit smaller. (You might be interested in this dated but relevant piece from Jakob Nielsen.)
As for fixed-width sites, it's hard to say. Personally, I suspect that a lot of web designers just like to feel like they have a lot of control over their look and feel, and think the site looks "ugly" when you stretch it too far, so they don't let you do it. Probably not wise, but there you go.
Now I would like to ask real experts
on this topic -- I'm not a web
designer -- why fixed width layout are
still that popular and if there are
really good reasons for it.
Ah, both subjective and argumentative. I'm sure my argument won't convince you, but here's one really good reason, IMHO:
Presentation.
Just like a movie, the director has an experience in mind for the viewer. They frame the movie just so. They move the action at a given pace for the emotion they are trying to invoke in the viewer. Even though DVDs have had the "angle" feature since inception, few movies have ever given viewers the opportunity to watch the film from a different point of view, and if they have that viewpoint was still under the control of the director.
Now, any old sap can throw up a website, and for the most part they aren't interested in anything more than the content.
But real designers fully understand that the design must be understood as a whole. A wide layout has a very different impact on people than a multicolumn or thin layout. Reader eyes move in a certain pattern, and the text is intended to pull the reader along a path.
Those who claim that every layout should have certain features are shortsighted. There are no universally true 'rules', and trying to make an expanding layout a rule is shortsighted at best, and arrogant at worst.
-Adam
Here are my $0.02 and they are worth exactly what you paid for them (and if that's not a perfect example of the current economic situation... :-))
The layout of a website should be dictated by the overall user experience. This is in part determined by the accessibility, in part by the design, in part by the functionality:
Accessibility - as several people pointed out, letting the website use the full width of the browser without any control can result in quite a long lines that make it hard to read[1]. Making the text automatically layout in multiple columns is a potential answer to this problem, but it's really hard to achieve with CSS (that's gotta be the worst tool for doing layout humanity ever devised, but that's a separate topic) and is fraught with other issues as well.
I should note that you do have a point - most websites with fixed width do suck on high-DPI because they don't take into account the changed font size. However, that's not an inherent problem of the fixed width design; I've seen it with fluid designs as well.
[1] No, I don't have a citation. I, however, have tried reading on full-screen on my 24" 1920x1200 96dpi [2] and gotta tell you - after 15 minutes my neck is cramping from the constant turning of my head.
[2] The typical user still runs 1024x768 or 1280x1024 (based on instrumentation from the product I work on, with about little bit less than 10mln installs for the latest version). So yeah, I am not the typical user.
Design - most modern designs are very rich on graphical and video elements. Most graphical elements do not scale well with the document reflow and video does not scale at all. (I would again blame this on CSS - it's support for dynamic resizing of images is lacking some basic operations and there is aboslutely no support for building and control of the visual tree. But I digress again :-)) As such, disegners opt in for the easier approach.
Functionality - fluid layout is really good for dealing with big text chunks like documents. However, quite a few modern websites are in effect applications, not documents. They have multiple elements and controls and increasing the area on which these elements are scatered makes it harder for the user to keep all of them in focus.
Couple examples:
two control groups that are aligned at the left and the right end will be too far away from each other in full-screen width. Note: that can be alleviated by choosing to always keep all the controls grouped together, like most desktop applications do (almost all desktop apps keep all toolbars left-aligned).
a picture/video and associated text below it. On full screen there are two possible approaches for fluid layout:
a) scale the picture to the full width, at which point the text is visually lost
b) leave the picture the same width, but let the text flow the full width, at which point the picture is visually lost.
I guess my point is that the fluid layout is not the Holy Grail of all layouts and there are scenarios where it's not applicable. The designer and the developer of the webapp should choose the appropriate layout and implement it so that it meets the needs of the target users, delivers the best experience of the product functionality and adapts to the user environment.
I suspect that most web developers go for fixed width because it's by far easier to develop such a site (in addition, many Content Management Systems only offer a fixed-width layout).
Getting a dynamic layout to work well & correctly in different browsers is more tricky - but it is definity doable (I'm just recently working on that issue ;-).
And I do agree with you - I want web pages that dynamically adjust their contents to the browser size that I as the 'customer' like to work with (whether that's small or large). I don't like to be patronized into "not using my browser in full-screen mode" or anything the like...
You might try zooming in. Most modern browsers will zoom the whole page by default, not just the text. This preserves the page layout and uses more of your screen. Usually the shortcut is ctrl + + and ctrl + -. It works well on my laptop, at least
[Forget my mention of the windowmanagement, it wasnt on topic]
I currently run a big internet-community and we'll switch to fixed-width (for 1024px) design asap because we only get problems currently using a dynamic-width-layout: You cant rely on anything, and (the biggest problem imho) text gets to long, so there are only a few lines but the lines themself are much to long to overview.
Readability and Predictability
You need to know how things will be displayed to be sure it will be readable and pleasant to the eyes. By using a fixed width, you know exactly (almost exactly because of cross-browser support) what your users will see.
However fixed-width designs would be a thing from the past if browsers could support correctly exactly 2 CSS properties:
min-width
max-width
That would allow designers to design web sites that would be flexible and predictable. No more surprises and users can use whatever resolution they want.
In my experience, it is for two reasons:
1) Speed - it is generally faster to write a web page in fixed with, rather than trying to write one that resizes correctly at more than a small number of resolutions.
2) The designer of the web site isn't the ultimate approver of what goes into production - if you try to work with a flow instead of fixed layout you get questions about why it looks different on Sallys' PC vs the Big bosses, and why can't you move this over to here, etc, which are easier to fix by moving to a fixed layout.
Tabbed Browsers
Since I use a tabbed browser for day to day use, resizing my window every time I switch tabs is actually a bit of a hassle. I have the window set to the maximum usable width for my purposes, and to accommodate the "largest" tab that is open. For the remaining tabs, having fluid layouts is actually kind of annoying and distracting. Items and text jump around and change position depending on how I may have resized my window for another tab. Also, fluid layouts result in uncomfortably wide blocks of short (vertically) text.
For me, it's a lot easier as a reader to keep my eyes tracking properly on narrower blocks of text with lots of vertical scroll, and it's much easier when sites I'm familiar with stay the same size so that the layout and positioning is predictable, regardless of what I've done to my window to accommodate other tabs. I actually used to be a big fan of fluid layouts, but I find more and more that I prefer fixed layouts now that I use a tabbed browser.
I think the question shouldn't be "Why would you choose a fixed-width design?" it should be "why wouldn't you?"
Firstly, you need to cater for the lowest-common denominator. Many developers will be running on screens with resolutions like 1680x1050, 1920x1200 and 1280x1024. Some users will be using 1024x768, which I personally consider the lowest resolution you need to cater for (thank God it's not 800x600 anymore). If you fix the width to 960-1000 pixels then you don't run the problem of developers unintentionally making pages that can't be viewed without scrolling on a monitor with less than 1600 pixels (wide). Believe me it happens.
Layout on any non-trivial Webpage is hard. Throw in cross-browser support such that your page not only works but looks reasonably consistent and it's a huge problem. Now try to throw in variable width and it just gets that much worse if not impossible. Look at the payoff too: who is it going to benefit? A small minority of users that have high resolutions and actually want to stretch that content across the entire screen. I have a widescreen monitor and I won't maximize my browser for instance. Many people are like me in this respect.
Consider another problem: CSS. CSS s good for many things but is a royal pain in many others. For one thing. Now browser box model differences aside, there are still many quirks with how different browsers handle CSS and even if there weren't there are many trivial things CSS can't do and the only workaround is to do things by pixel.
As a concrete example, I'm doing some tables at the moment that are bursting at the seams. I'm reloading the contents with an Ajax call and replacing the contents. Now I at first tried to fix the widths of the columns with percentages. Doing it this way would be a prerequisite for not fixing the width. Firefox treated those as a suggestion and would resize them anyway even when it arguably didn't have to. I didn't get satisfactory results until I fixed the widths in pixels.
At the end of the day no website really cares if it stretches across 1600 pixels or not. That's what it comes down to.
I've worked with a lot of artists. They design a layout to be pleasing and clear. They want the presentation to match what they designed. Artist-driven design leads to fixed-width. For brochure sites, fixed width makes a lot of sense.
For sites with rapidly-changing content (news or shopping, or most anything driven by a CMS), I much prefer fluid, full-screen designs.
One of the biggest concerns that fixing the width of a website solves is readability. If you let a site be arbitrarily wide and have a block of text using that entire width, it becomes very difficult for people to read. If you make the font size bigger to compensate, then you destroy the experience for people with smaller screens.
On the other hand, if your content is visual or modular and you can make it fill up the page more intelligently, you might have a case for a totally fluid layout.
But I agree with the others who question why you would maximize a browser on such a big display. Why not make your browser window smaller? You'll be more productive and you'll stop worrying about it at the same time.
Many browsers do a better job of scaling websites to be larger than they used to; Firefox 3, at least, grows the entire page when you zoom in, not breaking the layout.
If you want it to take up more screen real estate, use a lower resolution. This can be useful if you're displaying a website on a large monitor up on a wall for public view. Otherwise, take #theomega's advice and use the rest of your screen for other windows.
As for a little (of the very little) of what I know about web design and fixed width sites:
They tend to make good use of white space and draw your focus down the page. Cluttering up the page by cramming every last corner with content is what designers call "visual intimidation." It's difficult to figure out what's important versus what's not.
They feel more "finished", like a picture in a frame instead of like a photo print thumb-tacked up on a cork board.
"It has a resolution of 1920x1200, so all fixed-width sites waste space
The form factor is only 15". So I have to use larger fonts and the text won't fit into these crammed layouts any more, sometimes even getting obstructed by other elements."
There is a good reason for that. If the paragraph are stretched too wide, it gets more difficult to read. Humans need a "break" after about 15 to 20 words and that is EXACTLY why we don't have books that are very wide.
The higher resolution allows you to have MORE details BUT it also depends on HOW you use the space. I never maximize the browser and PC's are built for window multitasking, not ONE window at a time.
The whole point of being able to adjust the size of your browser window is to better see the content of a web page, in the way that suits your situation. If the page isn't going to adjust, why not just make browser windows a single, fixed size?
If I have a big monitor, I want to be able to stretch my window out and have the content correctly fill it. If I need space for another window, I want to be able to shrink my browser window down and have the content correctly adjust by changing the layout (until a certain minimum point, and then by switching to a scroll bar, of course.)
Fixed width layouts are perfectly acceptable.
Fluid layouts are nice, but are more difficult to implement, especially if there are more than two columns and source div order is important.
Line length is an issue regarding readability, but this interacts with font size. So you have to balance width against likely font sizes on screen.
Nowadays, it's reasonable to assume that 1024 x 768 and up is the vast majority of the desktop user market, so you can safely design for 960 px fixed width -- for screen media type.
A couple of important constraints:
ensure is that horizontal scrolling
is never required by the user
if conversions are an issue, make sure
that clickable things -- particularly
"calls to action" or anything than
makes your cash register go
"ka-ching" should not fall to the
right of the 770th pixel or so --
just in case.
But another consideration is handheld media. You should provide alternate CSS for handheld media type. Many of these screens are under 400 px wide.
Delivering a site that looks good and functions on a wide variety browsers, devices, display widths and viewport sizes is a moving target and continuous challenge.
As regards the filmstarts.de site, it is definitely a mess, but the problem is not that it is a fixed width layout, but rather with how the layout is designed and implemented. There are good and bad implementations of fixed width layouts, just like there are good and bad implementations of fluid layouts, or semi-fluid layouts with fixed width elements, etc.
I put it down to laziness. Fixed width layouts are simply easier to design and make look nice because you do not need to worry about the size changing. This, for example, makes it really easy to add images, since you know what size the layout will be.
Personally, fixed-width websites really irritate me. I like to use large monitors. I paid a lot of money for them, so I'd like to make use to make use of them instead of having most of it be left blank. This is made even worse by sites which refuse to get larger if I increase the font size. I don't have the best eyesight and often use larger fonts to read text on websites and nothing is worse than a fixed-width layout leaving me with three words per line and a mostly blank screen...
As far as I'm aware while all the reasons cited are valid, the primary reason is that a lot of machines in monolithic institutions like banks and government orgs are still on fixed and somewhat archaic low resolutions. It's just the lowest common denominator sadly.
I personally like fixed width sites better. I am not forced to mess with my browser window to get a line size I can deal with. I personally find very long lines very hard to read. I also just think it looks better although that is 100% completely subjective.
I have designed and worked with both. Some aspects of variable width sites make displaying data easier. The only problem I have had with them is due to right aligned navigation which was a little messy when it could move based on the user's browser setting.
My final answer - both are fine and each have their place.
I just came across this site, which actually has a link in the top right corner that lets you switch between fixed and fluid.
http://developer.spikesource.com/wiki/index.php/Home
A major point for using fixed width is that the designer can actually control the way the webpage looks irrespective of browser environment. I see two reasons to use FW:
The designer wants the webpage to look all the same.
The designer lacks time/wish/... to test their page in different modes and in different browsers, and just avoids the risk of webpage layot starting flying around.
I didn't make fixed-size layout until I switched to a 32 inches monitor. It is very hard to read the text if the lines goes over 32 inches. I've learned appreciate text that do not span over more than 1,000 pixels, and I have switched to fixed layout since.
But I agree that reducing the content width to < 800px is a pain when you have a big monitor.
Most users lack understanding of how to use a browser properly. When the day come such that users actually know how to use a computer then you will understand that fluid width is the obvious choice for web sites.
I am frequently forced too. None of the 3 developers here has a strong background in design, and the dictated rules and implementations we strive for reflects this. It is an area I want to improve in.
Liquid layout using % as unit can adapt to any screen.
Some layouts must use fixed column design. If there's table or image in the column, you have to use fixed column, or the table or image will break the column in liquid design.
In grid layouts with heights of the grid normally fixed, it's better using fixed column or the widths may got uneven.
It's upto the content of webpage to use elastic column or fixed column layout.
Long lines of text can be difficult to read. For the website I work on we limit the width for usability and readability. We have also designed our site to scale well using CTRL-+ to zoom.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
In a discussion with co-workers today, I lamented that I can't ever remember what an icon means, and have to hover over them to see the tooltips, and thus to find the button I need.
On their side, they were saying that when the text needs to be translated, it might not fit (German vs English for example), and that every place where there is text, including tooltips, it needs a translation. So plain icons are easier.
What is the best tradeoff in useability for the extra work of text vs the subset of users who are icon-challanged?
I personally prefer text and hate icon-only UI's. I know that other people think the other way, equally strongly, either because of internationalization or because their brain works more rapidly with images than with text. If you choose one or the other exclusively for your UI, then part of your user base will be unhappy with your choice. (Sometimes this is the right choice, depending on how extensively the UI will be used.)
Internationalization is really not that difficult, except for finding a firm to do good translations of your text. The programmer portion of internationalization is pretty straightforward. However, I've known a number of programmers who prefer the all-icon method as it's less work. I've personally had to replace one all-icon-no-text UI that the users didn't like. The users said they could not remember what the icons meant.
I think more typically, many advanced users will prefer icons and many beginning users will prefer text. However, a number of advanced users prefer text. IMHO, any good UI will provide tooltips, so you need to translate your interface no matter what you do.
The most friendly solution is to offer both text and icons, possibly with a settings choice to disable one or the other.
I worked with people in a Human/Computer Interactions group and was raked over the coals for using icon-only. They had studies about comprehension, error rate, and speed of using UI's and a good icon/label combination won every time, all else being equal.
Localization should be a non-issue. You may have to localize the icons anyway and localizing a label (as long as it's stored as text and not as bits) is easy. In terms of size in the UI - that's another matter entirely. If you can't fit the text, I'd claim that your UI is too cluttered.
Really they both have advantages and draw backs. Text must always be translated into different langugues, and sometimes a single word will not be able to effectively describe the action of a button. For example, how would you describe the X button which closes a window in Windows. We know what it does, and most people I know call it the X button, but it doesn't describe what it does. It's a lot easier to put a button with an X symbol (or icon if you will) than put something like "close window".
That being said icons also have drawbacks. As you eluded they may not always be clear what they do. The user has to be able to put the icon in a social context to understand what it does. This may not always be possible. Also, icons in one language may not be understood in another, leading back to the translation problem. Icons can be advantageous in certain areas as they can take a complex concept and show the user with a small amount of space. (like to take a picture show a camera, or delete something showing trash can).
The trade off is really in a case by case basis. If you have power users who really understand the application they are using and the surrounding subject, you are probably ok with using them. If you have people who use computers once a month and don't really care to learn it is going to be confusing. Its the amount of information you can convey with a single symbol (icon, picture, letter) vs. the potential frustration of the users and the overall rejection of your program.
Make sure you have a way to get both. Screen readers have a horrible time with icons.
I hate icons, because I never know what they mean even if they're perfectly intuitive (like this world icon that means hyperlink above this box in which I'm typing). Several Unix terminal applications provide a choice between:
text
graphical icons
both
That's nice. I usually like the text on a prominent button, because the meaning of the button is much more clear and the mouse target can be a little bigger.
Its a cultural thing as some symbols (icons) mean different things to people of different cultures, backgrounds and experiences. There are global symbols that one could assume to be 'known' by the general population, i.e. the 'save' icon...
It is a fine line, but i think the tooltips are a good way to help out those who dont understand the meaning of the icon. Perhaps a set of options to have the buttons (icons) render with text instead of the icon image ? This could be a user preference in the application.
Perhaps a good reference would be some of the "extensively" used icons in microsoft applications such as 'Word'. I am generalising here, but microsoft applications are almost eveywhere and they have done all the R&D into suitable / effective icons.
You don't mention if this is for a web application, but if it is then you have to provide the text at least as a backup if the user has disabled images, is using a screen reader, or other limited interface.
two things i guess
the decision should be the result of usability research and properly quantified, rather than a dev's gut feel or whim.
an icon that doesn't carry an obvious meaning is a bad icon and should be changed.
all that said, IMO: Icons with a tooltip/mouseover text equivalent, with bonus that this can carry a reminder of the keyboard shortcut.
(Note: I use "button" here to mean "the UI element on which the icon and/or text is located.")
I think in almost all cases it's important to include text either on the button itself, or at least on a hover-over tooltip on the button, so that in the event that the icon's meaning isn't intuitive to a particular user, the user can find out the meaning by reading the text. (Note that the translation work still needs to be performed in either case.)
A typical case for not including text directly on the button itself is when space is at a premium; when you want to fit a lot of buttons into a small area. Examples include the "toolbars" used in many desktop applications, and also in some web applications -- for example, the buttons that appear just above the StackOverflow answer text entry field!
A good case for including icons is when the button doesn't always appear in the same place, and the user would benefit from being able to quickly visually scan for where the button is located. For example, if I have a lot of programs open on Windows and I want to quickly find my instance of Firefox in the Windows taskbar, I'll look for the little orange icon, rather than reading the text on each taskbar button.