I know they are, but my co-worker doesn't believe me. He keeps telling me that Google crawls the inside content and caches it just fine. According to Google, it does crawl them, but doesn't guarantee doing it properly.
Any thoughts why frames are bad for public web sites?
There are various usability and accessibility issues with frames:
link can open in the frame it is enclosed in (e.g. a side pane);
can break the forward/backward navigation;
difficult to bookmark;
are not easily searchable (likely to see the content in Google, etc.);
break on browsers like Lynx, that are console/terminal based;
difficult to size properly (e.g. consuming height on widescreen monitors for banner frames);
can break with screen readers and magnifiers (for blind users and visual impaired users);
See http://www.angelfire.com/super/badwebs/ for an example of what not to do.
Frames are more difficult to bookmark and, therefore, more difficult to share with others.
http://www.yourhtmlsource.com/frames/goodorbad.html
IFrames (like HTML tables) are not bad. However, people were abusing them quite a lot, thus giving them the bad name.
IFrames do represent a good concept - single visual representation of documents coming from different sources, while keeping the DOM trees properly separated and isolated.
The problem arises when a script in one of the DOM trees needs to access the elements in another tree. Or when people want to reference the document location, which happens to be the URL of the root document, and fail to realize they need to location of the secondary document.
But the biggest problem with frames is that there are sites that want to encapsulated other sites in frame and trick the user to think they are interacting with the framed site, while in fact interacting with the outer one. This is the primary reason why most websites will employ some form of frame-busting scripts for their login pages.
Update: It's Friday and we need some fun, so here's the (obligatory) link to Jeff's post on frames-busting-busters-busting... :-)
At the beginning ...
The idea behind framesets is great. It's alive and kicking today; check StackOverflow's left side panel, or the header. They are fixed divs, which is basically the same thing as having frames, although a lot more flexible.
The very concept of keeping some part while changing another is simply necessary by the logic of webpages. We need something to stay where it was (typically navigation) while we go through a lot of details in the main area. Framesets served this purpose very well, they were easy to use and fully supported by all browsers, meaning 3 at that time (Netscape, IE, Opera).
Then we scorched the sky
The real, practical problems with frames had nothing to do with their basic concept. Instead, it was us being only human. I followed this whole debate very closely so believe me when I say these were the real charges against frame technology:
Designers hated them. Yes, that was the deadliest punch. Everything looked square and straight. They hated it. They wanted arcs and image backgrounds and rounded borders. Now they have it in CSS3 - guess what, they're drawing squares. #whatever
Programmers had trouble with them. It was inconvenient to follow the logic of frames, and you had to do some extra work. I mean, some. Today it's a lot harder to create AJAX solutions for the same problem, but no one complains. #whatever
Websites could include one another. This was painful for some site owners because they worked hard on something and another fella used it as own content. Later, they invented same origin policy, but it was way after starting to hate frames. Content stealing is still an issue today, absolutely unrelated to whether we have frames or not. #whatever
Back button worked differently. Yes, it was a bit annoying. But it was not the frame concept's fault, again: it was browsers who did this to us. Could have been solved easily, but nah, browsers kept going back one by one, not providing the site a way to implement its own "step back" method, and alas, this is still happening today. #whatever
So instead of coming up with a solution, the world's web developers decided to hate frames. They ditched it, and now we live in a world where there are lots of better solutions - but with a lot more effort. This was not the only feature going thru the hate-ditch-reinvent-love cycle; see vertical centering and flexbox, aka the table tag debate - and it will happen many more times because it's always easier to point fingers at something than to learn why it's great.
I don't hate frames; don't miss them either, they belong to a somewhat outdated world of web. But they were a good solution for something, and there's a chance we'll see something similar in the future just as CSS grids came back to implement what table layouts did before. The same community who hates the old solution will happily embrace the new and tell you why it's not the same at all.
I think this story has a single takeaway:
Implementations come and go.Concepts stay and evolve.
Depending on what you want to do, most things done with frames can be done with CSS. CSS stylesheets are compatible with all MODERN browsers, meaning your website will look the same if using firefox, chrome, or IE 7(with some tweaks). Also backward-compatibility is not a concern as users can view the content even with CSS off (where as a website using frames and without a frameless version of the site will be useless to a user with an old browser), it just won't be as stylized. It's also quite easy to learn, and once you get the hang of it you'll wonder why you haven't learned it in the first place.
I know this is an old thread but..
Been using Frames almost all my life and I think they are great. I still have a few websites using frames and I cannot understand why they are being droppped. Read all of the comments above and disagree with most of them. Problem is most people never bothered to overcome the issues.
Link can open in the frame it is enclosed in (e.g. a side pane);
Yes it can, but if you do it properly it does not matter. Frames can in fact be very useful for this precise reason, as clicking on a link will only refresh the frame the link it pointing to, not the entire webpage. In the days of dialup modems at very slow speeds this used to be extremely useful to save on bandwidth and make webpages appear superfast. Dont forget, there are still people around the world today (albeit not many) that have very limited internet connectivity at very slow speeds. (people on sailboats in the middle of oceans, those die hards that dial into the internet using HF radio. Oh and those that live in war zones that revert back to poor mobile phone signals, or possibly even need to dial into the internet in another contry using their infrared connections on mobile phones via a modem)
can break the forward/backward navigation.
Yes it can, but if you do it properly it wont.
difficult to bookmark
again very easy to overcome, requires very little additional work, but can be easily overcome
are not easily searchable (likely to see the content in Google, etc.);
break on browsers like Lynx, that are console/terminal based;
Already covered by somebody else earlier. Personally I have never even heard of Lynx (apart from the deodarant). In fact it used to be quite useful that pages werent searchable when you did not want to get spammed by bots searching for email addresses... Unfortunately Google or somebody figured out how to do it.
Difficult to size properly (e.g. consuming height on widescreen monitors for banner frames);
Clearly whoever wrote this has hardly any experience of using frames. This was exactly why I used frames because I could make it work on any screensize in what some would refer to as Fluid views on modern web design
can break with screen readers and magnifiers (for blind users and visual impaired users);
I suppose it can if screen reading software and maginfiers are cheap and rubbish and dont know what they are doing, probably them that complained about it, but there are others that manage this easily.
The only argument that I think makes sense, is that people were abusing them. Now I would not know how that was done, as I am not in that game, but I suppose it would be easy to use frames to show a copy of lets say a financial payment page inside another another frame which is completely hidden to make it look like the user is on the correct page. Therefore conning users out of their beer tokens. But I believe more modern webbrowsers have been updated to overcome these issues and not allow re-direction where encryption certificates are used.
I can therefore understand why they would want to restrict the use of frames, but dont understand why they need to completely remove what is a pretty good bit of tech. (Bit like saying we are going to stop people from using 0 when they do math as it causes can sometimes cause problems when you add many 0's together.)
I still have some websites that use frames and wonder when I am going to have to re-code them one day.
PS. also note that google calendar and youtube allow one to imbed pages into websites and both of these use iframes.
Related
We all know that showing inexistent stuff to Google bots is not allowed and will hurt the search positioning but what about the other way around; showing stuff to visitors that are not displayed for Google bots?
I need to do this because I have photo pages each with the short title and the photo along with textarea containing the embed HTML code. googlebot is taking the embed code and putting it at the page description on its search results which is very ugly.
Please advise.
When you start playing with tricks like that, you need to consider several things.
... showing stuff to visitors that are not displayed for Google bots.
That approach is a bit tricky.
You can certainly check User-agents to see if a visitor is Googlebot, but Google can add any number of new spiders with different User-agents, which will index your images in the end. You will have to constantly monitor that.
Testing of each code release your website will have to check "images and Googlebot" scenario. That will extend testing phase and testing cost.
That can also affect future development - all changes will have to be done with "images and Googlebot" scenario in mind which can introduce additional constraints to your system.
Personally I would choose a bit different approach:
First of all review if you can use any methods recommended by Google. Google provides a few nice pages describing that problem e.g. Blocking Google or Block or remove pages using a robots.txt file.
If that is not enough, maybe restructuring of you HTML would help. Consider using JavaScript to build some customer facing interfaces.
And whatever you do, try to keep it as simple as possible, otherwise very complex solutions can turn around and bite you.
It is very difficult to give you very good advise without knowledge of your system, constraints and strategy. But I hope my answer will help you out to choose good architecture / solution for your system.
Boy, you want more.
Google does not because of a respect therefore judge you cheat, he needs a review, as long as your purpose to the user experience, the common cheating tactics, Google does not think you cheating.
just block these pages with robots.txt and you`ll be fine, it is not cheating - that's why they came with solution like that in the first place
I wanted to run some captcha possibities past people to see if they are easily by passed by bots etc.
What if colors were used - eg: there is a string of 10 characters are you ask people to type the red characters of where there are 5? Easy to bypass?
I've noticed a captcha on plentyoffish that involves typing in the characters under the circles. This seems a touch more complex - would this be more challenging for bots?
The other idea I was thinking was putting the requirement in an image as well meaning like in no. 1 above - you can put "type the red characters" in an image and this could change with different colors. Any value here?
Interested in what people think.
cheers
Colours are easy to bypass. A bot just takes the red channel and gets the answer. It is even easier than choosing between many possible solutions. The same applies to any noise that has another colour than the letters the user needs to find.
Symbols that don't touch the letters are very easy to ignore. Why would a bot even look at those circles that probably always stay at the same position? (valid but wasn't asked here)
Identifying circles or other symbols is easier than identifying letters, if one can do the latter, a simple symbol is no challenge.
I think captchas are used too frequently in places where they aren't the best tool. For instance, are you trying to prevent registration spam? Why use a captcha rather than email validation?
What are your intentions and have you considered alternatives to the (relatively ineffective) captcha technology?
As a side note, if you have to use them, I prefer KittyAuth myself :) http://thepcspy.com/kittenauth/#5
Color blind people will have trouble separating red from green letters. People who have trouble reading and understanding descriptions, or have other disabilities may have trouble reading the captchas too.
In some of these, the texts are so mangled that almost everyone has a hard time reading them.
I think captcha's, if used at all, should be quite easy to read. The one with the dots and triangles is doable, although it's a matter of time before someone writes an algorithm to hack them. It is very easy for computers to read this kind too.
The best way to deal with this, is increase moderation. Make your site so that it isn't rewarding to spam it at all. Don't make it the problem of your users.
Also, if you're gonna use captcha's, it may be better to build something yourself than to use common libraries. I've found that these are easier hacked, probably because it is more rewarding to write a captcha solver for something that is used by thhousands of sites.
No matter which CAPTCHA you construct, spammers will find a way to work around it, given enough incentive. Large CAPTCHA services like reCAPTCHA, for instance, get bypassed by outsourcing solving them to cheap labor in India(source).
If you run a small site, your best bet is to make your own mini-CAPTCHA, which asks a simple question. If it isn't a standard question, isn't a standard CAPTCHA module and isn't a large site, it isn't worth it for the spammers to automate bypassing it.
I've been working on a community site for an organization at my university, and we've had trouble with spammers registering, despite us using every CAPTCHA module in the book. As soon as we made our own simple one-question CAPTCHA, all spam stopped. The key to preventing this sort of spam often lies in uniqueness.
I am designing a photography website for a client. The client requested that I make sure no-one "steals" her photos from the website.
As far as I know there is absolutely no way to do this reliably. Obviously disabling right click with JavaScript is very easy to get around.
Even creating the website in Flash does not solve the problem because anyone can just take a screen-shot and easily get anything they can see on the screen.
Short of putting a watermark or logo on each picture, is there any way to make sure no-one takes pictures off the site?
I am pretty sure your only options that do anything for real are watermarks and making sure all the photos are low resolution.
Clearly if I can see the photo then you have sent me the pixels and I can copy/save them if I want. Not much you can do about that.
Watermarks and posting lower resolution pictures are the best ways to prevent 'stealing' (in terms of the ratio between effort and efficiency, that is); in my opinion, of course. You could also use other easy tricks such as a script that disables right-clicks, as you've mentioned.
One other way, that is a lot more complex, is to send your pictures to a Flash viewer, through an encrypted channel. For example, there are some digital music stores that have this small Flash music player that receives the actual song over an encrypted channel. This prevents you from using pack analyzers to grab the data that is being sent.
You can always just press PrtScr, though...
There is now way to do this but you should place a copyright text to your site, licence all content with GPL if you desire and watermark it.
As far as I know there is absolutely no way to do this reliably.
Correct. The only way to make sure it's impossible1 to steal the images is to omit them from the page.
1 Even then, a "hacker" could break into your house and steal the hard drive that the pictures are stored on. Security is hard!
You can make it harder, if you use a viewer (say flash, but this can be Javascript as well) that uses a low res image when fully zoomed out, and uses multiple pictures when zoomed in. The one downloading the picture will have a hard time pasting all those pictures together.
That won't stop people who do have the knowledge to paste it together, but they may be willing to to pay for the use of those pictures, while other 'hobbyists' may want to use the pictures just for their own site or something.
I think you should ask yourself against who and what use you want to protect the pictures. If you don't want anyone to use them, not even a kid pasting it in their homework, you shouldn't post it online at all. But in general you want to protect the pictures from being used illegally in commercial activities. In that case a clear copyright notice is step one. Low-res versions and watermarks are nice extra's, but they will seriously affect the look of the site. So then you will have to ask whether this is like a gallery or a museum where people are supposed to be looking at the full size pictures, or it's just a catalog where people can buy them (like those many stock foto sites).
If I just want the world to see my pictures, it will be hard to protect them. I'd choose for a good copyright message, a signing or a name and url in a corner, and hope for the best.
If I wanted to sell my photo's, I'd not make a website at all, but rather put them up for sale on a stock foto website to reach a larger audience and make use of their infrastructure.
Whatever the choice, it is vitally important that you tell her that you cannot 100% protect pictures on the internet, and that you will not be responsible (i.e. paying for the pictures) if they leak out.
When doing hallway usability tests do most of you make your apps fully or near fully functional? Or do you just make sure the links or flow chain correctly? Or do you just draw on paper and go with that?
I'm would like to test early on a prototype and am trying to find a good balance. But at the same time am worried that some non functional parts might actually not give representative results.
Thanks.
Usability tests, hallway or otherwise, only need the functionality that you need to test. In most usability tests, you should go in with specific design questions to answer and develop your prototype to the point where it can answer those questions. For example, if you need to test if users understand your indication of the sort order for a table, all you need is a paper picture of the table showing the sort indication (with the table contents blurred) and ask them how the table is sorted. If you need to test the IA, all you need is a bunch of web pages, empty except for a title, that are linked through the navigation menus.
You only need the pages relevant for the tasks you give your users. If you’re just testing the IA, then you only need the pages on the normative path. If you are also testing error recovery, then you need the pages off the normative path along with the full navigation controls. If you are also testing error detection, then you need content on the pages as well.
You can also simulate functionality when that’s easier to do. For example, in testing if users can figure out how to get a desired sort order, when the user clicks on a non-functioning control for sorting the table, you can say, “Okay, doing that will get you this,” and you take the mouse and select a bookmark that shows the table in the new sort order.
In hallway testing, if users breach the fidelity envelope, you can simply say, “I haven’t made that part yet. Let’s go back to A, and continue from there.” Of course, you should note that the user made a wrong turn in the task you intended for them. I haven’t had any problems with users complaining about non-functional features when I tell them up front it’s an incomplete prototype and we’re only testing the UI for features x, y, and z at the moment.
For low fidelity prototypes, I often call them “mockups” or “drawings” to users rather than “prototypes” to indicate the low functionality. You can put obvious placeholders in for missing content (e.g., “Blah, blah, blah…”, “TODO: Picture of product about here.”). If a user comments on something outside the fidelity envelope (e.g., “This symbol should be red to stand out more”), simply note it, and say that topic is under development (e.g., “Thanks. We haven’t started work on the colors yet. We’re just trying to figure out how to organize the site right now.”).
Usability testing with limited-fidelity prototypes is really necessary for iterative design to be feasible for most projects. Otherwise, you waste too much work developing things that have to be redone.
A couple things to remember:
Test early and often.
The goal of usability testing is to find problems with the UI, not Q/A your code.
Therefore, if users can see the parts of your UI you are interested in testing and interact with them in a realistic way (e.g., click on buttons and links), you should be able to collect useful data. If some links are dead-ends, that's okay, as long as there's some way for users to recover and continue on. Basically, with prototypes, the "correct" path should work, but it's okay if incorrect paths don't (as long as there's a reasonably quick way to get back on the correct path). Even static storyboards (non-functioning drawings of a UI) can provide you with some information if you ask the right questions, e.g., "What would you do on this screen if you wanted to view your shopping cart?").
I would suggest a couple rounds of usability testing. First on paper, perhaps later on screen, generally throughout the application lifecycle (take an Agile approach to it).
There is a good argument to be made for paper prototypes. When users see a screen, even limited functionality, they may be hesitant to suggest changes since it looks "done."
Make no mistake, it's not trivial to get it all down on paper, but that's where I would start. Probably start with just a section or two of the application. And make sure somebody with good people skills and/or explaining skills is there to walk the user through it. Have a second person on-hand to take notes. Try to ask open-ended questions, etc.
For a hallway test, I would test with NONE of the functionality implemented.
Test against designs done on a whiteboard or on paper. You'll be surprised at how much you find out in these minimal mockups. And they are very inexpensive to make!
Functional prototypes are for later. If you give your usability subject a functional interface, they are much less likely to question whether you've implemented the right set of features in the first place.
I would make the UI functional, so that the user can really play with it, it will be much better than a static image. People can tell you whether they feel comfortable on the UI.
I would make sure everything in the UI works, or at least takes you to a clear, unambiguous message pointing out that the feature isn't implemented yet.
Showing prototypes to clients with a disclaimer up front about how feature X doesn't work yet will usually be ignored. They'll try out the prototype, click on featuree X and indignantly reply "Feature X doesn't work! This really needs to work in the final version! Why doesn't it work?". The client is confused and unhappy about the product, and it's frustrating for yourself because it overshadows the positive feedback. Besides, you told them it didn't work, why can't they use their imagination to envision how it would work in the final version?
Make it work, be it with a rough version, dummy data, or even a simple message saying "would show results sorted alphabetically now".
I was making a website for a music band, and i was wondering the best way to play background music on the website without interrupting the flow of the music (even for a split second).
At the moment, i am considering using frames, but this is not supposed to be good practice. Please someone tell me how i can do this. I would prefer to use HTML to code the website as i have not yet mastered coding in flash.
This might sound controversial, but here's an idea: Don't play music on your website. Seriously, don't. I think everyone knows how incredibly annoying that is, and asking a group of software developers to help you out with that is going to be like asking a group of sheep the best way to make a lambskin coat.
If you really have to do it, frames would be the simplest way, so I'd do that. But you're not going to do it anyway, right?
I can think of four ways:
Frames, as you said.
Make your entire website in Flash and have only one page. You need to know Flash to be able to do this, which could make this difficult.
Pop-out your music player. This is probably the easiest approach, but the downside is this could be annoying, and a lot of web browsers these days would block it.
Use AJAX and dynamically load all your site content within one page, like Gmail. Users will need to have newer browsers, and this will take quite a bit of coding on both the client and the server side.
The only way to prevent the music from stopping is to not let the page your music component is on reload. Currently the only way to do this is to use frames, unfortunately.
The only alternative is to develop the whole site in Flash or another technology that doesn't rely on changing pages as navigation.
It wouldn't be pretty but you could do it using AJAX. Have the master page with the header/footer/navigation controls with a big empty content div, and instead of regular links you have calls to AJAX functions that return HTML to be injected in the content div.
I tend to agree with the others who recommend frames. It may be considered "bad practice", but so is playing background music in the first place.
As was said, to do that you have to prevent your website from relaoding.
An option to achieve this might be to use asynchronous requests to modify your website content without reloading the whole page, that's basically what Ajax is about.
That being said, I sort of agree with Alex here : dont' play music.
This may be a topic for another post, but why would you cosnider IFrames to be good practice? you could out the content you want to change into an IFrame and have your code running your music player ouside it. When you load a page it woul load on the IFrame. Just a thought...
You would most likely need flash or a new window (pop-up) outside of the window.
Don't use frames. Ever.
EDIT: To all the people downmodding and commenting on this, not a single person has given a valid reason why you SHOULD use frames.
Just to clarify my position, please read ANY article on usability, the web, and frames.
For those still learning (and to those old people to dumb to update)
Frames break the unified model of the web.
Frames cause problems for search engine robots.
Frames make URLs stop working.
Frames break bookmarking.
Frames make printing more difficult.
Frames hurt accessibility.
Frames increase technical complexity.
and the #1 reason to not use frames......
USERS HATE THEM!
http://www.456bereastreet.com/archive/200411/who_framed_the_web_frames_and_usability/
Are there seriously this many people out there suggesting frames are a valid solution in 2009? How disappointing.