Hacker News Reader

Hacker News

Comment by tehlike | Hacker News Reader

Parent Full thread

tehlike

Google wave pretty much provided infrastructure for Google docs and other realtime communication products.

Similarly, Google plus was not a total failure - Google Photos came out of it.

View on HN

> Similarly, Google plus was not a total failure - Google Photos came out of it.

Making it even more ridiculous that they killed off Google Reader for it (or didn't bother to revive it afterwards)

EDIT: Also, they already had Picasa Web Albums since 2006. I don't know what exactly Google Photos has to offer over it in terms of functionality.

> I don't know what exactly Google Photos has to offer over it in terms of functionality.

The machine learning assisted search. For example, if I want to find photos of whiteboards that I took to record a meeting, I type in "whiteboard".

Also automatic curated photos, reminders and so on. A mobile app that is very simple and easy to use.

And automatic sharing suggestions based on the people that was at an event.

Especially with Flickr stagnating at the hands of Yahoo, Google more or less had the market for a high-quality photo sharing site to itself had it wanted it.

That said, surveying today's landscape, it would appear that there isn't actually a huge amount of demand for either full resolution user-curated sites focused on photography or RSS readers. The vast bulk of users are fine with throwing their baby and cat pictures up on more casual sites like Facebook and Instagram or getting their news from Facebook/Reddit/etc.

It’s interesting you are thinking of them as the high-quality niche, saying not a huge demand for full resolution.

Problem wasn’t full resolution, it was re-compressing your originals. Photographers that care about full res, care about original quality.

While there were (and still are) options like SmugMug for photogs, Flickr was the only prosumer one supporting unlimited original quality.

Also on the “stagnating” comment — at some point is it possible you’ve hit a reasonable photo site, and shouldn’t tinker much?

Turns out photographers who posted and curated 50,000 photos are not big fans of having the rug pulled out from under them by people in marketing trying to change the UI for their own engagement metrics.

>Also on the “stagnating” comment — at some point is it possible you’ve hit a reasonable photo site, and shouldn’t tinker much

I actually think that's somewhat fair. I could come up with some things that I wish were better with Flickr and there are probably lots of things I'm not thinking of. But I still use it and, in conjunction with Lightroom, I find it's a pretty good way to display a curated collection of edited photographs (as well as serving as a backup of last resort).

I did object to the big UI change a few years ago and still don't really love it. On the other hand, I don't actually use the web interface much. I upload from Lightroom and I mostly view from a tablet.

I thought writely gave them that?

Docs pretty much threw out all the Writely code and switched over to a new editor built from scratch (codename "Kix") in 2010. I'm not sure if Kix used code from Wave, though.

I'm pretty sure there is no lineage from Wave to Kix (which, yes, was the code name for the modern incarnation of Docs). Kix is more of a descendant of the architecture of Google Sheets.

Source: I am one of the original authors of Writely, did not work on Kix but I was still at Google when it was being written, had a minor role in reviewing the design.

What about the OT code and the comments?

Bear in mind that this was almost a decade ago, and I wasn't directly involved. With that caveat: the core mechanisms for client / server coordination in Kix were a direct descendant from Trix (short for "Matrix"), which was the original code name for Google Sheets. And Kix was developed by a team in New York, an offshoot of the Trix team which was also in New York. Writely (post-acquisition) was in Mountain View, and Wave was in Australia (I forget which city), and the picture that might give you of how closely the various teams communicated is probably accurate.

I don't know whether Trix originally used OT specifically, or the Kix team borrowed that idea from Wave. But the basic idea of clients performing small, tidy logical operations and then synchronizing them in realtime through a server was part of both Trix and Kix. Writely used a very different (and more primitive) approach.

I don't know anything about the origin of the comments feature, but my guess is that there was no connection to Wave, except (again) possibly a bit of inspiration. The Wave team was very separate, both geographically and organizationally, and the tech stack they built was very disconnected from anything that was going on with Trix, Kix, or Writely.

Wave was in Sydney, the only Google engineering office in Australia. I walked through their space before they had even announced the project internally. All that almost everyone in the company knew was that Lars and co. were busy on something big. The rest of the office was aware of its nature, but sworn to secrecy until the announcement. I remember going by a whiteboard, looking at this architecture diagram (wavelets?) and still having little clue on what it was all about, other than it having something to do with threads. :-)

I was asking because I have a vague recollection that Kix borrowed OT ideas or even code from Wave. But then I was even more removed from both teams than you. Or maybe it was just an aspirational thing from management to find a silver lining in the Wave shutdown.

You might be right about the OT idea, or even some code, having been borrowed from Wave. I wouldn't necessarily have known about it (or I might simply have forgotten). But I'm pretty certain that Kix as an overall project was much more closely connected to Trix than to Wave.

Out of curiousity: with these full rewrites, do they at least learn from the mistakes of the previous code? I can imagine there is potentially great value in that.

Good question. I don't know how much of that was done in this case. I can say that at the outset of the Kix project, they did ask me for advice about pitfalls. (I was skeptical that it could be done at all using the browser technology of that time; they proved me wrong. One of my concerns was proper handling of complex international character sets, both for input and rendering.)

Kix is a drastically different architecture than Writely, so many lessons would not have been applicable. Writely was built on a contentEditable DIV, so the data model was literally whatever junky HTML the browser's contentEditable implementation would create, and synchronization was implemented by performing three-way diffs on the HTML code. It was very much a dancing bear, in the sense of "the amazing thing is not how well it dances, but that it dances at all". ...but I digress. My point is that the mechanisms and challenges of that approach are entirely different than the Kix approach. I think the important lessons would have been product-level rather than code-level.

I dunno, the description you just gave of a dancing bear gives me the impression that your advice must have contained quite a bit of insight about past mistakes to avoid.

If Trix is Sheets and Kix is Docs, what does the K stand for?

I have no idea. :)

Hmmm, best I can come up with is a joke about cereal.

Reply on news.ycombinator.com