Mistakes in Web Design | Hacker News Reader

Mistakes in Web Design

useit.com

53 pointsiamelgringo40 comments

Open articleView on HN

1. Bad Search

2. PDF Files for Online Reading

3. Not Changing the Color of Visited Links

4. Non-Scannable Text

5. Fixed Font Size

6. Page Titles With Low Search Engine Visibility

7. Anything That Looks Like an Advertisement

8. Violating Design Conventions

9. Opening New Browser Windows

10. Not Answering Users' Questions

I find myself wishing HN didn't violate 1 and 3.

I don't know what you're talking about when you say HN violates #3 on the list.

http://skitch.com/sant0sk1/1sfy/top6

Can you guess which stories I've already clicked thru?

Yes, but we can't tell which comment threads you've looked at.

The problem is, there might be new comments even if you visited the thread.

But there's a remedy for it and it's simple: the link includes the number of comments in that discussion, so that your browser can change the color if the number of comments has changed since your last visit.

Edit: e.g. http://news.ycombinator.com/item?id=268389&c=21

That is so very simple and genious. PG, better implement this pronto, shouldn't take more than five lispy, lispy seconds.

Very clever. I may do that. But it would take more than 5 seconds, because I have to think about the best way to distinguish between visited and unvisited links.

Why not just use the same slight-fading that's used for submission titles?

(Also: simply changing the link URL would mean users could make a change in their local stylesheets, even if there's no styling change at News.YC.)

This is neat. I've been using this technique ever since stumbling across it in "Building Communities with Software" by Joel Spolsky (http://www.joelonsoftware.com/articles/BuildingCommunitieswi...). Money quote:

Q. Why don't you have some kind of system so I can see what posts I've already read?

A. We have the best system that can be implemented in a distributed, scalable fashion: we let everyone's browser keep track of it. Web browsers will change the color of the links you've already visited from blue to purple. So all we have to do is subtly change the URL for each topic to include the number of replies available; that way when there are additional replies the post will appear in the "unread" color again.

Anything more elaborate than this would be harder to build and would needlessly complicate the UI.

Let me introduce you to bookmarklets, specifically the "zap" bookmarklets:

https://www.squarefree.com/bookmarklets/zap.html

I wonder what I am doing wrong, as my visited links don't gray out like that.

Of course, now that I think about it, my Google results don't change color after visiting them either, so maybe it's something with my browser (FF3).

It's always seemed odd to me that the link to the comments for any article is small text and light gray, especially since the discussions are usually the real reason I visit the site.

Visually, the comments link should be on par with the article link. IMO

The power of #7 continues to amaze me. I've had times where I scan a page for something I know is there, and after a minute I realize I was skipping over it because it looked like an ad, completely subconsciously

#5 is a flaw in IE, not a web design mistake.

Edit (since my original brusqueness earned a downvote):

The flaw is that IE6 cannot resize text sized in pixels. IE7 fixed this with its new zoom feature, but left the old, broken resize method untouched. Every other modern browser can resize pixel-sized text.

I personally prefer sizing text in pixels because browsers handle ems and percents differently. Usually it works out fine, but it's really annoying to futz with fractions of an em because one browser rounded it up while others rounded it down.

Pixels also make the translation from mockups to code a tad easier.

Indeed — and it's almost irrelevant now anyway as IE6 is dying off.

You/we wish...

It's falling, but not that quickly. IE6 still has 25.3% market share: http://www.w3schools.com/browsers/browsers_stats.asp

And of course: "W3Schools is a website for people with an interest for web technologies. These people are more interested in using alternative browsers than the average user. The average user tends to use Internet Explorer, since it comes preinstalled with Windows. Most do not seek out other browsers.

These facts indicate that the browser figures above are not 100% realistic. Other web sites have statistics showing that Internet Explorer is used by at least 80% of the users."

No, I've seen plenty of sites that go to great effort to choose a font size (something that should be a user preference / fluid layout).

It is very aggravating on large displays, or for people with imperfect vision.

Why is specifying a font size wrong?

"It is very aggravating on large displays, or for people with imperfect vision"

But not specifying a font size is annoying to people with average resolution displays and good vision because the default size (16px) is too large.

But I understand now how makecheck could get annoyed: though pixels can be resized after page load, ems and percents take the browser's font size setting into account and are scaled appropriately the first time.

It's possible for the user to change browser settings; I have mine set to 14pt. Should a Web designer assume that the user has configured the browser to their liking or not? Should this assumption depend on what decade it is?

It's more complex than just enabling font scaling. Many designs are not tested after fonts have been scaled causing breakages which render the page illegible.

Additionally, for those shooting for the greatest cross-browser accessibility, different browsers scale differently based upon whether you define things in pixels, points, percentages, or ems.

> "The worst example of not answering users' questions is to avoid listing the price of products and services. No B2C ecommerce site would make this mistake, but it's rife in B2B ... Price is the most specific piece of info customers use to understand the nature of an offering, and not providing it makes people feel lost ..."

QFT. I pretty much immediately leave a site if the price is hard to find or figure out. If your pricing model doesn't fit in a neat little table (like http://github.com/plans), then you are going to lose a lot of customers who just want something now, and are willing to pay for it.

Making the customer call to negotiate some 'custom solution' (with associated 'custom price') just makes it a hassle for them to give you money. Instead, make it easy for people to give you money.

OTOH, if your product does not work out of the box then the customer who wants something now should not buy your product. Not listing the price prevents these customers from buying the product and then clogging the support line. :-)

I think that is why I avoid such sites. No price says to me that they don't actually have a product, but are willing to string me along with buzzword bingo until they can build something half-assed for me.

I know http://www.searchyc.com et al exist, but still do not understand why HN does not have its own search facility.

Because I have a lot of things to do and don't have infinite time. Implementing search right is not trivial.

Use google custom search?

But "real" Google's just as good for that: http://www.google.com/search?q=globalrev+site://news.ycombin...

I think it's reasonable to assume on a "Hacker News" site that the clientele will be up to figuring that out.

ok didn't know exacrly how it worked but "search YC" is actually awesome, why not just integrate their service?

In the mean time, can't you set up search powered by searchyc.com?

(At present I use Xichekolas' HN Toolkit GM script that does this.)

This is why $DEITY invented Lucene/Solr, Sphinx, etc.

Why not add a 'search' link to the top navigation that just links to searchyc.com? Estimated implementation time: 1 to 5 minutes. Then, when HN's own search arrives, you could replace that link.

Appreciating how busy you are, what you do (thank you), how HN is built, the fact HN is not a business par se, and that one would rather not have a feature than something poorly implemented, it nonetheless would still be helpful to many even in a basic form.

Generally, most people here are capable of finding what they want/need (e.g. using the methods repeatedly outlined throughout HN), but that is not really the point.

In most (especially YC) startups, such features are the first to be implemented even if initially they suck - the mantra being release early and iteratively improve.

Hence, I'd have thought search would have been high on the agenda and one of the first things done (even if not optimally - it doesn't have to be good, just 'good enough' to be useful, and can be improved over time) as it is a critical feature in almost every site these days and even on HN is one of the most repeatedly requested and asked-about things.

I don't think it requires infinite time either. :)

I don't really know why you'd want to search HN or an equivalent site, they're not meant for searching, they're meant for browsing

I think this page, as a counterexample, will prove you irrefutably wrong:

http://www.gabrielweinberg.com/startupswiki/Ask_YC_Archive

Ironically because of a flaw in Adobe reader #2 is also a security hole which allows malicious 3rd parties to run arbitrary javascript on your domain.

You should force all PDFs to download.

2. PDF Files for Online Reading

This should be #1. You can always search the site with google if I have to.

Reply on news.ycombinator.com