I swear it's so crazy the absolute random shit that gets banned here. Thank god for Tor, I guess, I was able to access the forbidden knowledge of...github?? brb about to create some social unrest.
----
Having read the article, I was curious how it could be utilized for everyday writing, tracking collaborations and stuff.
Maybe if you are doing editorial work, this could lead to controlling your workflow in a more cohesive way than docs? You have your text, I have my text, I don't lose my workflow behind your red tags.
> Maybe if you are doing editorial work, this could lead to controlling your workflow in a more cohesive way than docs?
I could see that happening. For the example I showed, though, as well as what you're envisioning, you'd really want to use the GitHub API to skin the experience.
And then, of course, you could do the same with GDoc.
Ultimately I don't care how it's done, I'm just looking for ways to make it easy for someone to teach others how to write and edit by presenting an orderly and easily navigable sequence of edits and associated narration.
The author’s use of Git versus Google Docs’ version history (which I find is excellent for tracking and annotating collaborative changes across a document) hinges on his claim that GDocs history is too complicated. He does not substantiate this claim; indeed, his use of Git seems extremely convoluted and complicated relative to GDocs.
However, using GDocs version history requires discovering it and understanding that it exists and not using anything else to do the job.
That sounds stupid until you start working at a company where "oh yeah we version this specification" means there is a Google Doc Word document in which each "change" consists of
- picking a color
- adding new things in text of that color
- using strike-through to cross out things which are no longer valid
, as opposed to using the document's version history as version history.
I can say that when you’re trying to compare versions gdocs and word are a little more difficult to use compared to how GitHub (or git) presents the diff.
Per https://news.ycombinator.com/item?id=32630551, this is a about a very specific scenario which GitHub happens to handle out-of-the-box (but awkwardly), and which GDoc doesn't (but perhaps could with scripting).
> I started at BYTE in 1988. During the pre-Web years, I wrote reviews and features for the magazine. In 1995 I switched into Web mode, created BYTE.com, and documented my progress in print and online.
This is interesting but I’m curious, how much use would something like this get?
Forget a paid product or any sort of licensing requirements:
If someone were to create a DocHub that treated docx files like txt files and had a plugin for word/OpenOffice used a really nice interface on top of git and came up with a way to intelligently represent styling changes (which git doesn’t because it only deals in txt.)
Would this sorta tool get enough use to justify maintenance? This feels like a niche within a niche.
If this service were easily self-hosted (i.e. on an intranet), it would serve the niche of people who for whatever reason cannot or will not use Google Docs, whose collaborative editing and version control experience is state-of-the-art, and unlikely to be surpassed by a competitor.
This could be a small but very stable niche—many companies that deal with sensitive data cannot use cloud services, often by law.
I have a hard time with the Google docs is the "collaborative editing and versioning" state of the art bit. My team has several long running docs that we maintain in it, and the UX for finding relevant comments around a blurb of text is bad. You can either (a) never resolve comments so that they always appear in the sidebar, cluttering the doc to no end or (b) tap the comment icon in the top right and scroll through resolved comments that have lost all relationship to the text body. I think there must be better solutions, but vendor lock-in means we'll probably never leave it (at least, not without major disruption).
My question is: "state of the art" for which purpose? For general collaboration I think GDoc is very good.
I'm going for a very specific purpose: enabling a teacher to walk a student through a sequence of narrated edits. The GitHub-based method I showed has proven to work in practice, but GitHub is a high bar for many. While GDoc doesn't solve the problem out of the box, I can definitely imagine a scripted solution that would, and I'd like to see that happen.
https://i.imgur.com/1m9LX0C.png
I swear it's so crazy the absolute random shit that gets banned here. Thank god for Tor, I guess, I was able to access the forbidden knowledge of...github?? brb about to create some social unrest.
----
Having read the article, I was curious how it could be utilized for everyday writing, tracking collaborations and stuff.
Maybe if you are doing editorial work, this could lead to controlling your workflow in a more cohesive way than docs? You have your text, I have my text, I don't lose my workflow behind your red tags.