It's a huge relief to look at a file on scribd and have the file be HTML, rather than flash.
I used to avoid scribd, but now I'll happily use it. As well as the pauses and slowdowns, even the flash text rendering is wretchedly bad in comparison with the HTML rendering I get in Safari.
Scribd have done a great job in moving over to HTML, and I'd expect the growth to keep coming. Good on them!
Can't find the transition item here on YCN, but the first article of the transition to HTML is:
Same here. I was using OReilly Safari the other day, which also hosts PDFs like Scribd. I kept cutting and pasting sample code from I book I'd purchased, then wondering why the code had ransom spaces inserted into it that kept breaking things.
And then I remembered: Safari is Flash, Scribd is HTML. This is why Safari cut and paste doesn't work.
I went from despising scribd to not minding it. Flash was inferior to pdf in a number of ways and didn't have many advantages; html actually has some advantages.
This raises the question, who can afford to build an internet application in flash these days? It seems that making heavy use of flash in any new product would be a big mistake.
There are still some things you can't do in HTML, eg. Google Pacman used Flash for sound because the HTML5 <audio> tag couldn't provide reliable timings. Google Wonder Wheel is in Flash (despite having had various HTML5 prototypes floating around) because FF/Linux's <canvas> performance is atrocious, and IE6-8 excanvas.js performance is borderline at best.
Just like how "mad" became "angry" instead of "crazy" in American English, or how "bade" more often rhymes with "fade" instead of "sad", the meaning of "begging the question" is becoming "begging one to ask the question".
It's a battle even less worth fighting, because "begging the question" in the old meaning doesn't serve any really useful purpose that can't be served more clearly by "assuming the conclusion" in most cases, and may itself be the product of a mistranslation from Greek to Latin to English. See: http://languagelog.ldc.upenn.edu/nll/?p=2290
I understand your point and have sympathy for it, but I just can't go along with it. I know it's just the grumpy old man in me, but I still prefer to push back (gently, I hope) against the misuse of words and phrases.
Great example of pivoting. (As Chris Dixon said: "Ask yourself: if you started over today, would you build the same product?" http://cdixon.org/2010/06/14/pivoting/)
Another tidbit I found interesting:
Now that the company has its HTML5 and iPad strategy in place, Adler says they are focusing on making Scribd more social and less reliant on search engines. Today, the majority of their traffic comes from Google, but Scribd is putting a greater emphasis on the social by closely integrating with Facebook.
If Facebook (rather than search) becomes the principal way that people find content online, that could spell big trouble for Google.
I suspect that a business/pleasure line will be drawn. Social networks tend to lead you towards entertaining content, where as people turn to Google for both entertainment and critical path content. In reality, I doubt that social mechanisms will do anything more than continue to boost Google traffic.
In this case, Scribd is baking a bigger pie. I doubt either Google or Facebook need to concern themselves with arguing over the size of the slices for this one.
I'm surprised at the meanness of some of the comments (is it contagious from TC or something?) and I'd bet five bucks that some of the very people who slammed Scribd for not doing this are now slamming them for doing it. Therefore I want to say again that this is the most impressive technical pivot I've seen a startup do in a long time. What they're accomplishing here is a lot more difficult than it appears, and it's only going to get better over time -- probably much better. This is a real contribution to making the web more usable for all of us.
I agree, I've started uploading my conference presentation slides to Scribd, and it's a much better experience than Scribd's Flash implementation ever was (and Slideshare's, for that matter). I tried the two sites multiple times over the years, and I never felt that there was a better experience than just putting the PDF for download.
However they achieve it, with "HTML5" or hacky auto-generated HTML markup standards from before, it's a wonderful technical achievement that should be applauded.
If you look at scripd's source code, you cannot really call it "HTML5". It's the same old nested DIVs with absolute positioning and class names such as "only_ie6_border". Plus some CSS3 eye candy. Hard to see why it couldn't have been implemented years ago.
It's not just about HTML5, it's about browser support and speed for the features they use. Browser performance has increased dramatically in the past few years and many people have upgraded to browsers with much better standards support. They still have some hacks, but they can also take advantage of HTML5 when it's available like they do with @font-face.
Google managed. (They've been displaying pdf's using HTML for ages now).
I know it's cool to hype up everything as HTML5 now, like it's something totally new and completely different to anything that went before, but it's not. It's just some extra features that make a few things easier.
They've been displaying pdfs as text for some time but it was very ugly — just enough to quickly see what's inside. “Quick preview” is new feature. They render pdfs but have raw text too for convenient copy/paste.
Google's reader should be much more light and perform faster, esp. in old browsers with slow DOM implementation. The disadvantage of this solution is non-native (for client) text rendering. Also things like embedded video and scripting would not work, but I think Scribd is not supporting those either.
So, not at all the same thing. Whoever downvoted you have some explaining to do.
> Now that the company has its HTML5 and iPad strategy in place, Adler says they are focusing on making Scribd more social and less reliant on search engines. Today, the majority of their traffic comes from Google, but Scribd is putting a greater emphasis on the social by closely integrating with Facebook.
So rather than relying on Google for most of your traffic, you'll rely on Facebook. Sounds like you're just changing one master for another.
Most of what Trip talks about is FB connect and recasting. I like the flash to html switch, but can someone explain why the flash to html5 conversion would increase time on the site for regular web users?
(I find it easier to understand why people who discover scribd through FB would spend a lot more time on site than someone who reached scribd via search)
I'm sorry that you felt the document viewing experience went backwards. If you're wiling to contact me directly I would definitely like to understand what is bothering you about the new experience and whether there is anything we can do to correct it.
Undoubtedly, from a PR standpoint we ended up timing the launch just right in the wake of the Steve Jobs fueled anti-Flash fervor. Total coincidence, though; I can't take credit for foreseeing that six months before it happened.
The press doesn't have anything to do with the user engagement (more specifically, "time on site") change, though. Only a tiny fraction of Scribd's users read TechCrunch or have any idea what HTML5 is. The majority really don't care and just unconsciously find the viewing experience less annoying, so they stay longer.
Exactly, and if you actually look at the numbers on Alexa:
http://www.alexa.com/siteinfo/scribd.com
The Pageviews/User and Time on Site went down since they released it in May. It's all PR BS.
Once a site's above a gameable threshold, Alexa's a decent metric of how unsophisticated users interact with it. If that's an interesting demographic to you, you can probably get some value out of Alexa numbers.
I don't see much of a dip in time on site. Note also that Alexa is heavily biased (who exactly installs that toolbar?) and that time on site in Alexa is a blend of time on site for new and old style documents. I know nothing about scribd's metrics besides what I read on the internet, but my guess is they're discussing time on site for exclusively converted docs, which you will not be able to see on Alexa.
I wonder if the numbers he quotes are based on comparing users forced to use the Flash view vs the new view. It sounds like instead he's largely referring to trends over time.
How's the new interface compare in terms of load time?
Thanks for the data point. Did the square roots render over the quantities. I'll have to check browsers, but Opera was a no go and Chrome is okay but not great.
User engagement is a convenient metric to use, because it's something that only they have access to internally. If pageviews had gone up, that would have been proper proof that their strategy worked.
This is similar to a diaper company changing the fluff on the diapers and releasing a paper saying customer satisfaction is much higher.
I used to avoid scribd, but now I'll happily use it. As well as the pauses and slowdowns, even the flash text rendering is wretchedly bad in comparison with the HTML rendering I get in Safari.
Scribd have done a great job in moving over to HTML, and I'd expect the growth to keep coming. Good on them!
Can't find the transition item here on YCN, but the first article of the transition to HTML is:
http://coding.scribd.com/2010/05/17/facing-font-in-html/