thanks for the AMA-like availability, really appreciate it.
One question from me: how would you pitch "new Sites" for a potential new customer willing to use it, but afraid his/her/their content might not last the next "modernization" sweep?
In other words: would you try to sell new Sites to a customer that values - and worries about - long term visibility of his/her/their content? If no: what is new Sites' value proposition, in terms of target market?
Thanks again.
Why do you (your team) really have do do this?
This is digital destruction. It's not about the features you shipped in 2008, and what those look like to a 2020 audience. It's about the content(!) which is part of the human creative endeavour.
Thanks for taking questions.
That being said, I hear the feedback, and I'll talk to the team about what we might be able to do, within legal and privacy constraints, to protect published sites.
Whether or not a site has had visitors recently isn't a fair measure of the importance of those sites -- for instance, there were examples of digital shrines in GeoCities and Yahoo still decided to eradicate them all. It was only thanks to projects like the Internet Archive that we haven't lost that period of internet history just to free up some disk platter space.
EDIT: I also am struggling to understand what this means:
> To me, archiving those sites doesn't feel like destruction, it feels like backing up unused content and protecting it for the user.
What does "archiving" mean here? Will the sites still be accessible or not? Is "archive" here a euphemism for "delete" -- in which case, how is it not like destruction and how is it like a "backup"? I'm not sure most people would consider "rm -rf" to be a backup strategy, but it definitely does have very good storage density.
My concern isn’t that the files don’t exist any more,I think it’s nice to zip it and add it to the owners gdrive, my concern is that the files are no longer accessible on the web. So all the links are broken, no longer in search, etc.
This seems like a much larger issue than archiving and it would be cool to hear how you all decided to take the sites offline.
Is it a cost issue? I imagine hosting a billion static sites shouldn’t cost much.
Yet when I visited the Classic Sites Manager it shows nothing. ("0 owned by you" and 0s all the way down the rest of the suggested filters.)
False positive, maybe? The email sounded like y'all were pretty certain: "We’ve identified that you own one or more ACTIVE classic Sites."
I'm having a hard time understanding why that would justify deleting that information forever. If anything, that suggests that providing static access would be enough and nearly zero-cost. Storage costs are a fraction of what they were.
I do a lot of searching for computer-related historical information, e.g., looking for rationales of "why something happened". Once information is destroyed it's often impossible to recover. No one might look at it for 30 years, and then there's only one retrieval but it was an important retrieval.
We've had a tremendous loss of recent information. This isn't the only example, but it's an important one. I'd like to see information retained, not lost.
I had forgotten about my Google site until seeing this posted. The last update of any kind was early 2013; most content was from 2011 or earlier. Some of the information on the site is wrong, a lot irrelevant, and worst of all, someone might not find my real site because of that one. I'd much prefer a dead site stop working to leaving it out there.
I mean.. if I don’t use my Facebook account anymore I wouldn’t expect Facebook to delete everyone else’s profile?
I tried the conversion tool on a dummy site and it opened a Google doc. I am not sure how an HTML page with embedded Google form with a script will be converted to new Sites.
UPD: I assume Google Sites has lots of customers (we were one of them)
Every page in the zip backup, no matter how simple, is around 59K because of all the Javascript Google wraps around simple text. My plan is to convert everything to some flavor of Markdown, but parsing this mess is not going to be exactly easy.
I appreciate that the goal of this backup was to allow me to host it "as is" somewhere else - with no possibility to edit it, which seems rather useless.
What would be really nice is to also get a zip file with some simple Markdown pages that include user editing (font sizes, bolding, etc), without everything being wrapped in Google's Javascript.
We first announced this gradual plan in 2017, with an update in 2019, and now we're providing the detailed plan. The goal was to provide adequate notice for people to figure out whether migration, export, or deletion of their classic sites makes the most sense.
EDIT: to the multiple people that are highlighting that 12 years is not a long time, I should clarify. I agree that 12 years in Internet time is not a long time, but it is a very long time in "how websites work" time.
One of the big challenges in the website builder space, something that Google. Wix, Squarespace, have all dealt with - is that when a user publishes a website, there's an expectation around the fidelity and look-and-feel of that website. The data model and architecture for how you represent a rendered page, how you render embedded content, all are very dependent on how browsers work at that time, and the maintenance of those things can become very challenging.
There was a big shift about ~7 years ago, moving away from a "pixel perfect" layout/raw html approach (Wix, Old wordpress, SQSP 5, Classic Sites), to one where there's some sort of grid-and-box approach where the render is responsive, there's reflow, there's padding and spacing and styling relative to the browser experience. It separates out content from layout to a certain degree in a way that is much more future-proofed and modern. This is how Wix ADI, Squarespace 6+, Wordpress Gutenberg, and new Sites work.
For all of those transitions, there was a platform shift, that required a complete rework of how the system works. My point about "12 years" was that the model of how classic Sites works is 12 years old, and new Sites was intended to match the modern way of how websites are built and delivered.
What should have happened is to turn Classic Sites (and new Sites) itself into Squarespace competitor.
I just see this as a massive failure of vision and execution.
Why didn’t they improve classic sites and added yet another product called Sites? May be I am seeing some internal politics surface as fragmentation of product line.
To your Squarespace comparison, Squarespace went through a similar transition - Squarespace 5 worked very similar to Classic Sites, and was replaced with Squarespace 6, which was a complete end-to-end rewrite.
Could have called it Classic Sites 2.
Huh? Did that 10 years ago. Perhaps we have a different definition of a "classic site".
To me a "classic site" is another name for a static site, that is, a website where the HTML to be served is pregenerated. Static sites are now coming back, not going away. But I always assumed that a website should reflow.
Perhaps when you say "classic site" you mean "site that assumes that all users have the same display size". I agree that such classic sites are nonsense today. But they were always nonsense. At no time was there a guarantee of any particular screen size for HTML, and it's always been easy to write HTML that just reflows. If you do that, your site works just fine.
GP didn't say “classic site” they said “classic sites website”. You seem to be interpreting that as intended to be a somewhat redundant and mispunctuated rendering of “classic site’s website”, but given that the context is a discussion for the shutdown of Google’s classic Sites in favor of only supporting Google’s new Sites mode, I think that it's just a capitalization-omitted rendering of “classic Sites website”, that is, a website using classic Google Sites as opposed to new Google Sites.
Also, people have technical knowledge here, even if they've never been hired by someone as "the best of the best," or having graduated from a top 10 CS school, so handwaving "fundamentally works differently" is not actually likely to be the enlightening description you might hope it would be.
Anything I can say would only detract from this.
This is modern Google.
Also RHEL support lifecycles are 11+ years, so for RHEL 8 released in 2019, that's a commitment to ~2030 right here and there & with doing this for many years for the past releases proving the point.
No wonder the most critical stuff (Bank, Stock exchnages, etc.) run on RHEL and not on some half baked Google stuff that will get deprecated from under them at a moments notice.
In this particular case, with Google Sites, maybe the decision was totally justified, I don't know. But, as a general trend across the technology industry, this type of explanation really bothers me, and I think it speaks to a serious mindset problem.
The fact that X is old and Y is new is not a reason to replace X with Y. Hammers are old, but they're also exceedingly useful tools. Users are familiar with how hammers work, and companies have become good at manufacturing them.
The question should be whether the new tool is better than the old one, and if it is, whether it's so much better that forcing every user to re-learn the new tool will be worth their while. And even then, it's worth asking why some of the largest companies in the world can't let both tools coexist, perhaps with the older one kept semi-hidden to avoid confusing new users.
Anyway, sorry for picking on you, I appreciate your willingness to pop into a somewhat-hostile thread. :)
This mobilification is a fad, and like many fads it will, too, disappear and have to be replaced (requiring many work hours) because ultimately it’s less usable especially for largely static content. There’s no option to keep a similar look and feel. “Mobile first” has been forced upon us and is now, with reflow, “mobile only.” Imagine if Arxiv required PDFs to be replaced by mobilified versions? So annoying and impractical.
Really disappointed. Google made a bunch of work for themselves just to reduce the usability of older web pages.
A website maintained with raw HTML still works just fine on modern web browsers. In fact, it works much better. Web pages built with some CMS systems often take 5-20 seconds to load, while the "raw HTML" sites load in fractions of a second. In fact, the speedups continue; JavaScript parsing is slow, while HTML parsing is fast, and HTML compresses like magic. So a "big" HTML file is transferred and displayed in remarkably fast time.
I wouldn't use raw HTML in all cases, but I also wouldn't use a fancy CMS in all cases.
It's okay to use different platforms for different purposes.
Google's misson is "to organize the world’s information and make it universally accessible and useful". Dropping sites on the cutting room floor because information in them isn't in a convenient format does not make that information accessible or useful.
My belief has always been "no". Google could kill off the entirety of GMail tomorrow, and I'd be disappointed, but totally understanding.