Hacker News new | past | comments | ask | show | jobs | submit login
[dead]
on July 14, 2011 | hide | past | web | favorite



Unfortunately this doesn't make the quality of the reporting any better.


You'll have to wait for CSS4 for that...


And even then you won't be able to vertically center without using divs nested three deep...


That's what I was thinking. An awful lot of effort for such a bummer of a website.


Very cool. Reminds me of an app I once co-built (with the now famous Mr. Bragger ;) that lets you skin an RSS feed with a customizable HTML/CSS template (compatible with Tumblr's template markup)

http://feedvolley.com/ (code: https://github.com/niryariv/FeedVolley ) - could use a little UI love, but pretty stable. If anyone's interested in building this further I'd be happy to help you get started.


Interesting. It can't seem to find a feed on https://grepular.com/ though. Is that because it's https?


It uses magpie RSS lib, but it's probably a pretty old version by now. If it doesn't auto-discover the feed you can just enter the feed URL, it should work.


Do you mean this was some kind of tumblr template markup to XSLT translator?


Basically just code that parses the tumblr markup (more or less..) and then enters the various RSS data for the relevant vars. No XSLT involved, though perhaps it wouldn't be a bad idea..


So basically it's all of TechCrunch's content with none of their ability to make money off it. This'll last long.


It'd be a sort of interesting legal issue if they got sued. Using the name 'tcfast' might be problematic. But what if it was a more general web-based RSS reader that reformatted any RSS feed into pages like this? If that's illegal, where's the line between that and Google Reader?


Google Reader is used for the private consumption of public RSS feeds but this republishes content.


Right, the private consumption by tens of thousands of Google Reader users. Is it private because they have to login? Like what is the difference? One is a web page with all of Techcrunch's content, and the other is a web page with all of Techcrunc's content. You think I'd go to tcfast.com only when I'm at a bar? Is it because I can read the contents from more than one site?


Well for one thing, TechCrunch puts out an RSS feed for the purpose of using an RSS reader to see their new content. Yes, both Google Reader and this site are "web pages" (in the sense that it's HTML over port 80) but the differences I think are obvious. For one, Reader is behind a login screen and you only see what you've subsribed to. There aren't any public pages generated from the content and the individual content viewed in Reader can't be linked to or indexed. TCFast.com is basically the exact opposite. They take one site's content and republish it publicly in a way that TC would likely have never approved of. The site has linkable content and the pages are indexable. You can eliminate the indexability but that doesn't take away from the core issue that they are republishing TC content and attempting to divert TC traffic with that content.


OK, what about popurls[1], alltop[2] and the like?

1. http://popurls.com/ 2. http://alltop.com


Those don't republish content, they post headlines and links to the original sources.


>all of TechCrunch's content

You forgot the illegally duplicated site designs (company livery, possibly trademark infringement, certainly someone would have a poke at passing off, ...).


ahem, you mean AOL's content. there is a cube in Dulles with the light on tonight with a C&D on the monitor.


It's also easy to design a site to load fast without ads or widgets. Redesign TC's site to load fast with the same ads and functionality, and I'll be more impressed.


Wouldnt be a bad idea for them to have a lite mode, very lightweight with mostly text based ads. Then just don't broadcast it widely, so your startup hacker types that prob won't click on the ads anyway get a more streamlined experience while everyone else who is happy with the regular site sees it as is.


The links on the top bar of an individual article page are in the form of http://tcfast.com/?backTo=/2011/07/14/larry-page-earnings-ca...

But "backTo" parameter also accepts full URLs, so something like http://tcfast.com/?backTo=http://cnn.com/&t=g will happily redirect to CNN.

This might not be desirable for you, because in effect it will transform your site to a free redirect service ready for use by spammers.

You should check the value of "backTo" parameter and redirect only inside your own site.


thanks. fixed now.


There is a reason the majority of news sites (well, any good news site) limits the width of text; wide text is hard to read. Although the HN version that lists everything with just the title is great, but the actual post display is awful, even though it's supposed to be inheriting how HN displays posts it should still be limited :(


That's a common opinion, yes. Some users prefer to actually take advantage of their screen width to read more content at a time. It also proves particularly convenient when trying to skim for particular information without reading everything.

Part of the justification for using narrow columns relates to the difficulty of finding the starting point of the next line when your eyes jump a large distance to the left. That advice applies quite well to books, and much less well to more structured content. For instance, on Hacker News, most comments don't have a wall of text with no paragraph breaks, and comments have strong delineation, so a narrow text width doesn't actually help.

That said, if you have the type of content for which a narrow text width does help (which TechCrunch sometimes does), please don't limit it to a specific pixel width; please use em instead, so that the width gets larger with the font size. That way, when users hit Ctrl-+ to override a site's smaller-than-the-browser's-default font size, the site will show about the same amount of text on each line, rather than producing narrower lines as the font grows.


>That way, when users hit Ctrl-+ to override a site's smaller-than-the-browser's-default font size, the site will show about the same amount of text on each line, rather than producing narrower lines as the font grows.

That is stale 2008 advice. Every browser but ie6 uses zoom to resize pages. Text is resized on ctrl-+ regardless of px vs em. The days of sizing things with em's is long over, and these days it is counter-productive.


Text is resized, but not necessarily content. Also note that that behavior is configurable in several browsers, including Firefox, for people who don't want to have to choose between reasonably sized text and crisp non-fuzzy images.

Also, many browsers that support zooming don't necessarily let that zooming override a size specified in px.

In any case, why would specifying the width of a column of text in em be "counter-productive"?


In addition to jcampbell1's remarks, which are completely correct, the zooming override issue you mention is, in my experience, nonexistent. I may be wrong, but I have not recently* encountered it on FF, IE, Opera, nor Chrome.

Em sizing is counterproductive because 1. That's not how most designers think, (We use Points, Pica, and Pixels.), 2. It's unnecessary for scaling with normally configured browsers, and 3. If someone changes their default type size, I am NOT going to support them: they have full knowledge of how to change the setting to fix a suboptimal page, and they have chosen to have suboptimal pages in the majority of their browsing (You think leading and optimal line width don't matter just as much as text size?) To anyone who actually forces their typeface choice: please do so on a site-by-site basis--or at least typeface-by-typeface for those you find illegible. Please do not try to override the informed choices of typographically-aware designers.

Sorry if that sounded like a rant. :) I'm a designer, and I'm passionate about my work being displayed and read the way I designed it to. Otherwise, I'd give every user a typeface selection screen when they visit my websites. The fact is, average users don't make informed choices.

*Within the past three years.


The web isn't print, it was never meant to be. The content you publish online is going to be displayed on any number of devices at various resolutions, scales, window sizes, colours, etc.

If you're a web designer, keep in mind that you're displaying content that's useful beyond the artistic merit of the typeface and other decorative elements. If you want to show off a design, make a PDF or an image. If you are making content useful to the widest audience you can reach, there are compromises that have to be made.


The thing is, type isn't decorative. It's integral to the presentation of content. [Good] designers know how to make type legible and readable, as well as appealing, to the greatest number of people. I'm not talking about preserving type in syndicated content, just in the original format. Good designers also know how to present content in a way that is effective on a variety of platforms.


I have enormous respect for designers, and I know full well that I, a programmer, can't do what you do and that anything I might produce that puts pixels on a screen benefits immensely from a qualified designer's input. That said, those are poor arguments.

1. Tough? Learn to think better. What would we tell a programmer who doesn't want to use recursion because they "think in loops"? What would you tell a carpenter who didn't want use screws to put your new furniture together because he "thinks in glue"? Units of measure are a tool, and your facility (or lack thereof) with a tool doesn't affect how good it is.

2. I actually admit to some ignorance about browser scaling algorithms, so you may be entirely right here. In any case, I think it's the least important of the issues at play.

3. I submit that it's more important to make sure that your users can use your websites in a way that's comfortable to them, rather than that they should be able to bask in the glow of your unsullied brilliance. I don't mean that I should be able to randomly change fonts around because today I like Georgia and tomorrow I'm going to like Chicago. I'm wondering what happens when your site suddenly starts getting traffic from Israel, and all your new users are using Google Translate to turn it into Hebrew. Not only do your font choices go out the window, but all your ragged right just became ragged left, and some page elements may have have spontaneously rearranged themselves. (See http://translate.google.com/translate?js=n&prev=_t&h..., for example.) Or what if some of your users are colorblind or elderly or dyslexic, or just have trouble reading your type selection for any of a myriad of reasons? Is it more important that your design should remain just how you like it, or that they should be allowed to read it? Before you answer, read this: http://tigerbeatdown.com/2011/07/14/harry-potter-and-the-oh-... It's not about web accessibility, but the major themes are still there.

One of the incredible things about the web is that not only do we have the power to make the content we're producing available to an extraordinarily diverse population, we have the power to make it so that they can all read it in a format that works for them, as individuals. When you have to design a poster that's going to get sent to a printer and plastered over bus stops, everyone waiting all over town is going to see the same poster. When you design a web page, everyone who sees it gets a separate stream of bytes and a separate display to see it on. Why not let each user find the best web page for them, instead of forcing them all to see the best web page for you?


I agree with most of your post. I'm not saying designers should actively hinder accessibility or make users uncomfortable. We should do the opposite.

Still, in 2003, ems might have been best practice. In the modern web, ems and pixels are equivalent when it comes to scaling. One shouldn't avoid a good tool because it's hard to learn. (Example: I use Vim for all my coding.) However, one shouldn't use a tool just because it's hard to learn. Ems, in my opinion, introduce bugs, make planning more complicated, and have no meaningful benefits.

Using ems is like avoiding functions and instead duplicating code everywhere it's needed. Ems behave differently depending on their scope, and they're a pain to keep track of.

There's a similar issue with percent-based sizing. Let's look at some css:

*{font-size: 75%} h1{font-size: 125%;}

What size is h1? I honestly have no clue without a calculator. It almost definitely contains fractional pixel value. There's no way I'm getting appropriate vertical rhythm with percents. It's the same for ems.

I might be entirely wrong. Maybe I'd fall in love with ems if I started working with them regularly. It's a personal choice, from my understanding of modern browser scaling. Pixels are a completely valid method.


First, please don't ever do something like "* { font-size: 75%; }" ; that literally means "take whatever readable font size the user's browser wants to use and shrink it by 25%". In other words, it means I'll almost certainly hit Ctrl-+ until the font grows back to 100% and the rest of your page will scale accordingly.

Second, I can easily tell you exactly what size h1 is: 25% bigger than the rest of the text on the page. If you're just going to start by assuming the browser has a given point size by default, and fill in percentages that result in exactly the point sizes you think the user ought to see, you're not really thinking in relative sizes, and you might as well use absolute sizes.

What method do you want to use to determine the font-size of h1? Presumably you have some idea in mind for how it should contrast with regular text. Try to answer that question without actually knowing the exact point size of the rest of the page text. If you can, then use that relative size in your CSS. If you can't, then perhaps browsers need more capable CSS so you can express what you want. :)


I agree. I gave that code as an example of a bad idea. For me, "If you can, then use that relative size in your CSS", has never been an option. Ems also have the same sizing problems regarding not knowing the browser's base text size.

I'm sticking with the quite capable pixel unit for the foreseeable future. :)


Because relative units are a painful and time consuming to deal with, thus counter-productive. How wide is the element that is 20em wide, that is contained by an element that is 20em wide? Yes, that is a trick question (it depends on the browser, and the css of other elements on the page). How wide is an element that is 200px wide that is contained by an element that is 200px wide? The answer is straightforward - 200px. In terms of CSS these days, 1px != 1 screen pixel.


i've limited it to 800px


In past few months or so I've found TC to be unusably slow. I don't know if it's all the ads/tracking/js being loaded but it takes 20 seconds or more for me to be able to actually interact with the page and so I've just stopped reading it. This is a very welcome new way to read it.


I just loaded the page, the last thing to load: post titles. Simply amazing that they don't see this as an issue.


Oh that is very very cool. Now Arianna will no doubt sue the crap out of you but still, it makes the site usable which was not something I thought was practical with just reskinning.


Awesome job! Are you just using the RSS feed?


rss and google


For speed, are you doing anything specific? (Would love to know hardware)


I don't read TC much, but this has got to be one of the coolest things i've seen all day.


Nice work. add a ?t=json option and this could get fun.


Nice work. I was going to do something very similar and call it bettercrunch.com - you beat me to it.


My favorite part is how fast it loads in the HN style compared to normal.


Wow, you just rolled all my most visited sites into one. And now I can read techcrunch again without my brain melting. Actually, that might not be a good thing, but thank you anyway. Great work


Thanx... and must say its awesome... Really, the annoying layout of TC now dumped into the gutter for good.. :D


Great app man, you deserve heaven, and by heaven i mean endless happiness while you are alive


Ha! I like the new design! That would be great if they made a piratebay and 4chan version!


The HN layout is so good and scannable, it almost makes me want to read TechCrunch again.


Its cool..a good demo of how the same content looks readable in different UX , neat!


Nice solution for all of those people complaining about the redesign.


I'd love Digg theme, SCR


more on the way.


I'm not a huge fan of TC but this is good way to skim articles.


Wow, this is very cool!


Any chances for Readability ? :)


TC should hire you


Nicely done.


Awesome


hobby project? nice work


You can also filter posts by authors.


Thanks - my MG Siegler-only TC is now a reality.


This is AWESOME :) Thank u.


Hah, I prefer the hacker news version. The nyt one is kinda not appropriate.


As a previous(albeit short-lived) developer at TechCrunch -- I approve.




Registration is open for Startup School 2019. Classes start July 22nd.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: