Pop-up ads are viruses
Pop-up ads are the scourge of the web -- they waste users' time and effort and erode their patience and trust of the Internet. Now Salon reports that one unethical company has taken it to an extreme by using pop-up ads and malicious coding to effectively deliver "malware" -- basically a virus.
"Thousands of unsuspecting visitors to a family entertainment site are discovering a cornucopia of unwanted, potentially malicious software on their computers -- the result of a pop-up ad campaign, a booby-trapped Web site, a compromised Web browser, and strange doings at a shadowy Los Angeles company.
[The ad] was designed to automatically redirect visitors away from Flowgo (no mouse click required) and to dump them at a booby-trapped site called KoolKatalog." "[A]ccording to virus experts, tens of thousands of Internet users have been back-doored by the KoolKatalog-distributed "malware," which they have added to their lists of malicious code for scanning. While researchers have not yet completely decoded all functions of the programs, they say two of the files" "attach themselves to victims' browsers and covertly monitor which sites they visit. Other components" "appear to enable the program's authors to secretly send updates or other files to the infected computer." This really takes the "viral" in "viral marketing" to an extreme.
Although most pop-up ads aren't intentionally malicious like in the KoolKatalog case, most are harmful in less obvious ways:
Computer viruses and pop-up (or pop-under) ads have a lot in common:
- They victimize unsuspecting, uninformed and unprotected users
- We've had to create specific utilities and software to protect users from them
- They interrupt users intended workflow
- They provide no value
- Users don't want to see either of them
- They are created by selfish, unethical people who have no regard for others
- When they "attack", they make users feel violated
May 17, 2002
Backlinking and Xanadu
In Ghosts of Xanadu, we discover yet another innovative idea from the past -- a way to "move forward through the rear view mirror" as stated recently by someone on the SIGIA Information Architecture list.
"Backlinking crudely approximates the two-way linking feature of an early hypertext system invented by Ted Nelson called Xanadu. Nelson coined the term Hypertext—the linking of information and a system for viewing it—in 1963"
I think backlinking is a very powerful concept from an Information Architecure (IA) standpoint. It provides rich links back to sites that link to the current page. These often would be pages highly related to the current page in some way. It's kind of like the Google "related pages" concept, but more timely as it would constantly age off old referrers and add new ones as they appear. It also would appear as part of the current page as auxilliary navigation.
Related:
- Wired magazine archives of articles on Ted Nelson and Xanadu -- Nelson is a strange character.
- The Xanadu Project home page
"PROJECT XANADU MISSION STATEMENT:
DEEP INTERCONNECTION, INTERCOMPARISON AND RE-USE
Since 1960, we have fought for a world of deep electronic documents-- with side-by-side intercomparison and frictionless re-use of copyrighted material. We have an exact and simple structure. The Xanadu model handles automatic version management and rights management through deep connection. Today's popular software simulates paper. The World Wide Web (another imitation of paper) trivializes our original hypertext model with one-way ever-breaking links and no management of version or contents. WE FIGHT ON."
- "One profound insight can be extracted from the long and sometimes painful Xanadu story: the most powerful results often come from constraining ambition and designing only microstandards on top of which a rich exploration of applications and concepts can be supported. That's what has driven the Web and its underlying infrastructure, the Internet." -- Vincent Cerf comments on The Curse of Xanadu (September 1995)
In Ghosts of Xanadu, we discover yet another innovative idea from the past -- a way to "move forward through the rear view mirror" as stated recently by someone on the SIGIA Information Architecture list.
"Backlinking crudely approximates the two-way linking feature of an early hypertext system invented by Ted Nelson called Xanadu. Nelson coined the term Hypertext—the linking of information and a system for viewing it—in 1963"
I think backlinking is a very powerful concept from an Information Architecure (IA) standpoint. It provides rich links back to sites that link to the current page. These often would be pages highly related to the current page in some way. It's kind of like the Google "related pages" concept, but more timely as it would constantly age off old referrers and add new ones as they appear. It also would appear as part of the current page as auxilliary navigation.
Related:
- Wired magazine archives of articles on Ted Nelson and Xanadu -- Nelson is a strange character.
- The Xanadu Project home page
"PROJECT XANADU MISSION STATEMENT:
DEEP INTERCONNECTION, INTERCOMPARISON AND RE-USE
Since 1960, we have fought for a world of deep electronic documents-- with side-by-side intercomparison and frictionless re-use of copyrighted material. We have an exact and simple structure. The Xanadu model handles automatic version management and rights management through deep connection. Today's popular software simulates paper. The World Wide Web (another imitation of paper) trivializes our original hypertext model with one-way ever-breaking links and no management of version or contents. WE FIGHT ON."
- "One profound insight can be extracted from the long and sometimes painful Xanadu story: the most powerful results often come from constraining ambition and designing only microstandards on top of which a rich exploration of applications and concepts can be supported. That's what has driven the Web and its underlying infrastructure, the Internet." -- Vincent Cerf comments on The Curse of Xanadu (September 1995)
May 16, 2002
Lyle, Lyle, Crocodile
A lot of people inadvertently come here looking for information on "Lyle, Lyle, Crocodile" -- a great children's book by Bernard Waber. There's actually a whole series of Lyle books. I've compiled a complete list of "all things Lyle" on Amazon.com. If you have children ages 3-8, these books are highly recommended. (Currently everything on the list with a rating is rated at least 4.5 out of 5 stars.) These books are fun for adults to read to kids or for kids to read on their own. They provide fabulous stories and illustrations. Books are cheap and make great gifts!
The list also has another kids' "Lyle" title: VeggieTales -- Lyle the Kindly Viking. VeggieTales are funny videos that have valuable lessons for kids.
For the record, I grew up being called "Lyle, Lyle, Crocodile" and "Lyle the crocodile" in grade school. Somehow I never read the books until I had kids of my own, and they are some of their favorite books. Currently this site comes up second on Google when people search for "Lyle, Lyle, Crocodile" due to my explanation of the site's name:
"The name Croc O' Lyle comes from people at work calling me "crocodile", as in the famous childrens' book "Lyle, Lyle Crocodile". The nickname went from "crocodile" to "croc" and then someone morphed it into Crocolyle. It's also a play on the phrase "Crock O' Gold" -- showing the Irish in my Heinz 57 hybrid genetics. ...and some people will probably say this whole thing is simply a crock."
This is simply an attempt to redirect people to something more suited to their interests.
A lot of people inadvertently come here looking for information on "Lyle, Lyle, Crocodile" -- a great children's book by Bernard Waber. There's actually a whole series of Lyle books. I've compiled a complete list of "all things Lyle" on Amazon.com. If you have children ages 3-8, these books are highly recommended. (Currently everything on the list with a rating is rated at least 4.5 out of 5 stars.) These books are fun for adults to read to kids or for kids to read on their own. They provide fabulous stories and illustrations. Books are cheap and make great gifts!
The list also has another kids' "Lyle" title: VeggieTales -- Lyle the Kindly Viking. VeggieTales are funny videos that have valuable lessons for kids.
For the record, I grew up being called "Lyle, Lyle, Crocodile" and "Lyle the crocodile" in grade school. Somehow I never read the books until I had kids of my own, and they are some of their favorite books. Currently this site comes up second on Google when people search for "Lyle, Lyle, Crocodile" due to my explanation of the site's name:
"The name Croc O' Lyle comes from people at work calling me "crocodile", as in the famous childrens' book "Lyle, Lyle Crocodile". The nickname went from "crocodile" to "croc" and then someone morphed it into Crocolyle. It's also a play on the phrase "Crock O' Gold" -- showing the Irish in my Heinz 57 hybrid genetics. ...and some people will probably say this whole thing is simply a crock."
This is simply an attempt to redirect people to something more suited to their interests.
May 15, 2002
Tacit knowledge and software usability
Jon Udell talks about how technologists are a breed apart.
"For years people have argued that software must relentlessly improve its score on the "mom test" and that is certainly true. But there's another angle here comes back to the KM aspects of blogging. When we narrate, we externalize what we know. We convert tacit knowledge to explicit knowledge. This can help software become more usable for two reasons. First, when technologists narrate what they know, they're more likely to realize how much tacit knowledge they have and expect in others. Second, when non-technologists narrate what they know, technologists can see more clearly that the expected tacit knowledge is missing."
[via David Watson]
Jon Udell talks about how technologists are a breed apart.
"For years people have argued that software must relentlessly improve its score on the "mom test" and that is certainly true. But there's another angle here comes back to the KM aspects of blogging. When we narrate, we externalize what we know. We convert tacit knowledge to explicit knowledge. This can help software become more usable for two reasons. First, when technologists narrate what they know, they're more likely to realize how much tacit knowledge they have and expect in others. Second, when non-technologists narrate what they know, technologists can see more clearly that the expected tacit knowledge is missing."
[via David Watson]
May 14, 2002
Web projects don't iterate, they use the waterfall method
In The Bottom-line of Prototyping and Usability Testing, How user-centred design techniques can make a cost effective workflow, Henrik Olsen commits blasphemy. He says that most web projects don't follow an iterative development process. Everyone talks about iterative development these days. How could Olsen say such things?! Yet Henrik's points ring true for me. I've talked to many web development professionals, and rarely do I hear stories about projects involving refinement and iteration of a product. Usually, projects are "greenfields", creating something new, or they involve a wholesale redesign, completely re-doing the application or site.
My own experience is that larger initiatives like ecommerce sites, extranets, and portals tend to follow a more iterative development cycle, but the more common basic web sites and smaller applications tend to follow a waterfall or mud-throwing type of process.
Olsen summed it up best when he said
"The majority of Web projects employ what we could call a no-nonsense approach to product development, where none but the most obvious steps from idea to the finished product are taken."
Many business people would say this "no-nonsense approach" makes perfect sense. Who needs extra steps anyway? The problem is that, generally, projects blow their whole budget and timeline in release one. They don't budget time or money for iterations (e.g. multiple prototypes) within release one. They don't have plans or budget for a release two.
In one of my presentations for development teams I advise them to listen for a warning sign related to project iteration that might indicate a product or project is ill-fated:
If the client says: “We’re going to put something out there and then get feedback.” you should ask the following questions to help assess project risk:
Q: How and when will they gather feedback?
If they're not sure or if they're just going to monitor complaints, then you're in trouble. Have they budgeted and planned for appropriate "feedback gathering" activities?
Q: Is there budget for the next iteration? Two iterations? Three iterations?
No budget often means no next iteration. So even if you get user feedback, you might not be able to do anything about it.
Q: When will the next iteration or phase start?
No timeline equals no real plans to fix anything. Clients rarely expect to find problems, so they don't plan on fixing anything. They see fixes as exceptions to handle if necessary.
Q: How long can users suffer if good usability isn’t there? What if it's really bad? What if the help desk gets a lot of calls?
If you can't move to the next iteration quickly, you could end up creating a lot of headaches for yourself -- not to mention negative brand impact, extra support costs and resistance to use the product in the future.
Q: How about just developing a paper prototype and getting feedback on it?
Rather than iterate product releases, which is costly, why not iterate within your release? Get user feedback on prototypes to accelerate your overall process and deliver a better product right from the start.
"Getting something out there and getting feedback" is often just an excuse for cutting corners on the User-Centered Design (UCD) process. Don't let your clients fool themselves into thinking they're being "iterative" when they're really heading for a waterfall.
Related:
- Joel on Software: Picking a Ship Date -- an excellent, realistic approach to managing software releases. If you're faced with "timeboxing" a project, you might want to consider Joel's thoughts on release schedules. It also applies if you're really and truly following an iterative lifecycle.
- BusinessWeek: IBM.com Looks for Big Improvements from Some Subtle Design Tweaks -- Quotes: "As we built a user experience map we decided we needed to focus on top to bottom information architecture," and "You can run into the trap of subjectively tweaking versus objectively tweaking,"
- UIWeb.com: Why Good Design Comes from Bad Design
[via Elegant Hack]
In The Bottom-line of Prototyping and Usability Testing, How user-centred design techniques can make a cost effective workflow, Henrik Olsen commits blasphemy. He says that most web projects don't follow an iterative development process. Everyone talks about iterative development these days. How could Olsen say such things?! Yet Henrik's points ring true for me. I've talked to many web development professionals, and rarely do I hear stories about projects involving refinement and iteration of a product. Usually, projects are "greenfields", creating something new, or they involve a wholesale redesign, completely re-doing the application or site.
My own experience is that larger initiatives like ecommerce sites, extranets, and portals tend to follow a more iterative development cycle, but the more common basic web sites and smaller applications tend to follow a waterfall or mud-throwing type of process.
Olsen summed it up best when he said
"The majority of Web projects employ what we could call a no-nonsense approach to product development, where none but the most obvious steps from idea to the finished product are taken."
Many business people would say this "no-nonsense approach" makes perfect sense. Who needs extra steps anyway? The problem is that, generally, projects blow their whole budget and timeline in release one. They don't budget time or money for iterations (e.g. multiple prototypes) within release one. They don't have plans or budget for a release two.
In one of my presentations for development teams I advise them to listen for a warning sign related to project iteration that might indicate a product or project is ill-fated:
If the client says: “We’re going to put something out there and then get feedback.” you should ask the following questions to help assess project risk:
Q: How and when will they gather feedback?
If they're not sure or if they're just going to monitor complaints, then you're in trouble. Have they budgeted and planned for appropriate "feedback gathering" activities?
Q: Is there budget for the next iteration? Two iterations? Three iterations?
No budget often means no next iteration. So even if you get user feedback, you might not be able to do anything about it.
Q: When will the next iteration or phase start?
No timeline equals no real plans to fix anything. Clients rarely expect to find problems, so they don't plan on fixing anything. They see fixes as exceptions to handle if necessary.
Q: How long can users suffer if good usability isn’t there? What if it's really bad? What if the help desk gets a lot of calls?
If you can't move to the next iteration quickly, you could end up creating a lot of headaches for yourself -- not to mention negative brand impact, extra support costs and resistance to use the product in the future.
Q: How about just developing a paper prototype and getting feedback on it?
Rather than iterate product releases, which is costly, why not iterate within your release? Get user feedback on prototypes to accelerate your overall process and deliver a better product right from the start.
"Getting something out there and getting feedback" is often just an excuse for cutting corners on the User-Centered Design (UCD) process. Don't let your clients fool themselves into thinking they're being "iterative" when they're really heading for a waterfall.
Related:
- Joel on Software: Picking a Ship Date -- an excellent, realistic approach to managing software releases. If you're faced with "timeboxing" a project, you might want to consider Joel's thoughts on release schedules. It also applies if you're really and truly following an iterative lifecycle.
- BusinessWeek: IBM.com Looks for Big Improvements from Some Subtle Design Tweaks -- Quotes: "As we built a user experience map we decided we needed to focus on top to bottom information architecture," and "You can run into the trap of subjectively tweaking versus objectively tweaking,"
- UIWeb.com: Why Good Design Comes from Bad Design
[via Elegant Hack]
Subscribe to:
Posts (Atom)