Online Office Hours with Google Docs

Cross-posted on the Google Student Blog

Guest Post: Alex is a senior at Harvard University, and interned this summer on Google's marketing team. Here he shares how he uses Docs to save time (and body heat) braving the cold Eastern winters

Now that the dorm move-in dust has settled and you have your class schedules all figured out, I wanted to share one of my favorite ways to use Google Docs that might help you stay on top of your work, save some time and maybe even stay a little warmer this school year!

I use the real-time collaboration in Google Docs to hold online office hours with my professors and TAs (teaching assistants). This allows me to collaborate, edit and revise my papers and reports in real-time no matter where my TAs or professors are on campus.

The air is already getting pretty crisp here in Boston and – if your school is in a similarly cold climate – you know exactly how nice it can be to avoid that icy trek across campus to office hours during the winter months. Here is how I use real-time collaboration in Google Docs to hold online office hours with my TAs so that I can review, revise and edit my assignments from the comfort and warmth of my own dorm room:

Set up some time to ‘meet’ with your professor or TA (hint: it's easy to do using Google Calendar). Sign into Google Docs at docs.google.com to get started.

Once in Google Docs, click the 'Share' button in the upper right hand corner. Enter your professor or TA’s email address in the ‘Add people’ field and click ‘Share’.

Your professor or TA will receive a link to the doc and a notification telling them that you have shared your doc with them. When they open the doc you will notice that their user name will appear in the top right corner of the screen. You are now collaborating in Google Docs.

Your professor or TA can now help you revise your doc in real time. Clicking the blue box in the upper right hand corner of the screen will allow you to chat with them and ask questions as you move through the doc. Your editor can also add comments to your doc without actually rewriting the text. Highlighting a passage and then selecting 'Insert > Comment' will allow them to make a note about that section to the right of the page.


Your professor or TA’s cursor will be visible as they move through the doc to show where there are currently reviewing or editing. Their cursor will appear in the color corresponding to the box next to their display name in the chat box. When they highlight a passage you will also be able to see their highlighted section in their color. As more people are invited to collaborate on the doc they will have different colors assigned to them so that you can tell who made each comment or revision.

Holding online office hours with Google Docs is just one of the ways to use Google to simplify your life as a student.

Posted by: Alex Roux, Harvard University

Read More

Keyboard shortcuts in Google Sites

We’re big believers in speed and saving time, which is why we’re happy to announce that we’ve added keyboard shortcuts to common actions like create page and edit page for site collaborators using Google Sites. You can see a full list of keyboard shortcuts here, or simply type Ctrl / (⌘ / on a Mac) to open the shortcut help.

You can disable keyboard shortcuts on the Sites user setting page. Are there other common actions that you’d like to see added to keyboard shortcuts? Let us know in the comments.

Posted by: Michael Verrilli, Software Engineer

Read More

More tools for viewing document revisions

We’re happy to announce that a new revision history interface is now available in Google documents. To see it, go to File > See revision history.

In the new revision history interface, you can see what changes were made at a glance.


Click on a time stamp in the right column to see what changes were made at a given time or use the arrow keys to quickly scan through many revisions.

Changes are color-coded based on each collaborator, making it easy to tell what has been added or deleted. For example, in the screenshot below, James (whose edits are highlighted in orange) deleted and added text while bmichael61 (whose edits are highlighted in green) removed a paragraph and added a comment.

Time stamps are also improved in the new interface. We’ve heard requests for time to always be listed, even for very old revisions and we’re listening: you can now tell afternoon edits apart from all-nighters.

The interface also batches revisions into groups of changes to make it easier to understand how a document has changed over time. To see a finer-grained list of revisions, click Show more detailed revisions.


This is just a first step for the new revision interface for Google Docs. We’re looking forward to more revision improvements in the future. Let us know what you think in the comments.

Posted by: Vance Vagell, Software Engineer

Read More

Import your files many different ways

A spreadsheet without data and numbers in it can get pretty lonely, which is why it’s important to be able to easily import files full of data. Today we’ve improved the import dialogue to give you a full range of options of where to put that data. You can get to the new Import dialog from the File menu.

For example, when importing a .csv file, you can create a whole new spreadsheet, append to the current sheet, add a new sheet to your existing spreadsheet or even replace your entire spreadsheet with this new version.

Now with the new custom delimiters option, you can also specify what character to parse your data file with, giving you maximum flexibility when dealing with your data files.

And finally we spruced up the dialog with a preview pane giving you a first glimpse to see how your imported data will look in your spreadsheet so you can make any changes if necessary.


Happy importing!

PS: If you're using Google Apps for your school or business, join us for a live webinar on Monday September 27th for a review of all the new Google Docs features we launched this quarter.

Posted by: Ben Mann, Software Engineering Intern

Read More

What’s different about the new Google Docs: Making collaboration fast

This is the final post in a three part series about the collaboration technology in Google Docs. On Tuesday, we explained some of the technical challenges behind real time collaboration. Yesterday, we showed how operational transformation can be used merge editors’ changes.

Imagine that you’re doing a jigsaw puzzle with a bunch of friends and that everyone is working in the same corner of the puzzle. It’s possible to solve a puzzle like this, but it’s hard to keep out of each other’s way and to make sure that when multiple pieces are added at once, that they all fit together perfectly. Making a document collaborative is a little like that: one challenge is coming up with a method to let multiple people edit in the same area without conflicting edits. A second problem is to ensure that when many changes happen at the same time, each change is merged properly with each other changes. In Google Docs, the first problem is handled by operational transformation and the second problem is handled by the collaboration protocol, which is the subject of this post.

To open a Google document, you need code running in two places: your browser and our servers. We call the code that’s running in your browser a client. In the document editor, the client processes all your edits, sends them to the server, and processes other editors’ changes when it receives them from the server.

To collaborate in Google Docs, each client keeps track of four pieces of information:

1. The number of the most recent revision sent from the server to the client.
2. Any changes that have been made locally and not yet sent to the server.
3. Any changes that have been made locally, sent to the server, but not yet acknowledged by the server.
4. The current state of the document as seen by that particular editor.

The server remembers three things:

1. The list of all changes that it has received but not yet processed.
2. The complete history of all processed changes (called the revision log)./li>
3. The current state of the document as of the last processed change./li>

By carefully making use of this information, it’s possible to design the client-server communication such that all editors are capable of rapidly processing each other’s changes in real time. Let’s walk through a straightforward example of how client-server communication is handled in a document.

In the diagrams below, the two outer columns represent the editors: Luiz and John. The middle column is the server. The oval shapes represent changes inputted by the editors and sent between the clients and the server. The diamonds represent transformations.

Let’s say Luiz starts by typing the word Hello at the beginning of the document.

Luiz’s client added the edit to his list of pending changes. He then sent the change to the server and moved the change into his list of sent changes.

Luiz continues to type, adding the word world to his document. At the same time, John types an ! in his empty version of the document (remember he has not yet received Luiz’s first change).

Luiz’s {InsertText ' world' @6} change was placed in the pending list and wasn’t sent to the server because we never send more than one pending change at a time. Until Luiz recieves an acknowledgement of his first change, his client will keep all new changes in the pending list. Also notice that the server stored Luiz’s first change in its revision log. Next, the server will send John a message containing Luiz’s first change and it will send Luiz a message acknowledging that it has processed that first change.

John received Luiz’s edit from the server and used operational transformation (OT) to transform it against his pending {InsertText '!' @1} change. The result of the transformation was to shift the location of John’s pending change by 5 to make room at the beginning of the document for Luiz’s Hello. Notice that both Luiz and John updated their last synced revision numbers to 1 when they received the messages from the server. Lastly, when Luiz received the acknowledgement of his first change, he removed that first change from the list of sent changes.

Next, both Luiz and John are going to send their unsent changes to the server.

The server got Luiz’s change before John’s so it processed that change first. An acknowledgement of the change was sent to Luiz. The change itself was sent to John, where his client transformed it against his still pending {InsertText '!' @1} change.

What comes next is important. The server received John’s pending change, a change that John believes should be Revision 2. But the server has already committed a Revision 2 to the revision log. The server will use OT to transform John’s change so that it can be stored as Revision 3.

The first thing the server did, was to transform John’s sent change against all the changes that have been committed since the last time John synced with the server. In this case, it transformed John’s change against Luiz’s {InsertText ' world' @6}. The result shifted the index of John’s change over by 6. This shift is identical to the transformation John’s client made when it first received Luiz’s {InsertText 'Hello' @1}.

The example above ends with Luiz and John receiving John’s change and the acknowledgement of that change respectively. At this point the server and both editors are looking at the same document — Hello world!.

The main advantages of this collaboration protocol are:

1. Collaboration is fast. At all times, every editor can optimistically apply their own changes locally without waiting for the server to acknowledge those changes. This means that the speed or reliability of your network connection doesn’t influence how fast you can type.


2. Collaboration is accurate. There is always enough information for each client to merge collaborators’ changes in the same deterministic way.


3. Collaboration is efficient. The information that is sent over the network is always the bare minimum needed to describe what changed.


4. Collaboration complexity is constant. The server does not need to know anything about the state of each client. Therefore, the complexity of processing changes does not increase as you add more editors.


5. Collaboration is distributed. Only the server needs to be aware of the document’s history and only the clients need to be aware of uncommitted changes. This division spreads the workload required to support real time collaboration between all the parties involved.

When we switched to the new document editor, we moved from a very simple collaboration algorithm based on comparing versions to a much more sophisticated algorithm powered by operational transformation and the protocol described above. The results are dramatic: there are no more collaboration conflicts and editors can see each other’s changes as they happen, character-by-character.

Well that’s all folks: we hope by reading this series you learned a bit more about what’s under the hood in Google Docs, and the kinds of things you need to think about to make a fast collaboration experience. You can try collaboration yourself, without signing in, by visiting the Google Docs demo.

Posted by: John Day-Richter, Software Engineer

Read More

What’s different about the new Google Docs: Conflict resolution

Editor’s note: This is the second in a series of three posts about the collaboration technology in Google Docs. Yesterday, we explained some of the technical challenges behind real time collaboration.

Think of the history of a document as a series of changes. In Google documents, all edits boil down to three basic types of changes: inserting text, deleting text, and applying styles to a range of text. We save your document as a revision log consisting of a list of these changes. When someone edits a document, they’re not modifying the underlying characters that represents the document. Instead they are appending their change to the end of the revision log. To display a document, we replay the revision log from the beginning.

To see what these changes look like, suppose that a document edited by John and Luiz initially reads; EASY AS 123. If John (represented by green) changes the document to EASY AS ABC, then he is making four changes:


Collaboration is not quite as simple as sending these changes to the other editors because people get out of sync. Suppose as John is typing, Luiz (represented by yellow) begins to change his document to IT'S EASY AS 123. He first inserts the I and the T at the beginning of the document:


Suppose Luiz naively applies John’s first change {DeleteText @9-11}:


He deleted the wrong characters! Luiz had two characters at the beginning of the doc that John was never aware of. So the location of John’s change was wrong relative to Luiz’s version of the document. To avoid this problem, Luiz must transform John’s changes and make them relative to his local document. In this case, when Luiz receives changes from John he needs to know to shift the changes over by two characters to adjust for the IT that Luiz added. Once he does this transformation and applies John’s first change, he gets:


Much better. The algorithm that we use to handle these shifts is called operational transformation (OT). If OT is implemented correctly, it guarantees that once all editors have received all changes, everyone will be looking at the same version of the document.

The OT logic in documents must handle all of the different ways that InsertText, DeleteText, and ApplyStyle changes can be paired and transformed against each other. The example above showed DeleteText being transformed against InsertText. To get a feel for how this works, here are a couple more examples of simple transformations:

• Style ranges expand when they are transformed against text insertions: {ApplyStyle bold @10-20} transformed against {InsertText 'ABC' @15} results in {ApplyStyle Bold @10-23}.
• Sometimes changes don’t conflict and there’s no need to transform anything. For example when a style change is transformed against a different type of style change, there is no conflict: {ApplyStyle italic @10-20} transformed against {ApplyStyle font-color=red @0-30} results in the same {ApplyStyle italic @10-20} because the range of text can be both red and italic simultaneously.

Collaboration in Google Docs consists of sending changes from one editor to the server, and then to the other editors. Each editor transforms incoming changes so that they make sense relative to the local version of the document. Tomorrow’s post will outline the protocol for deciding when each editor uses operational transformation.

Posted by: John Day-Richter, Software Engineer

Read More

A more fontastic Google Docs

Cross posted on the Official Google Blog

Documents without font choices are like photographs without colors. Just as shades of color can add depth to a picture, smart font choices give your text another dimension.

For a long time, the set of fonts that you’ve seen when you browsed the web has been quite limited. That’s because you could only use a font that’s already been installed on your computer. So if a website designer wanted all her visitors to see the same thing, she could only use fonts that are so ubiquitous that the chances are very high that every computer will have them. And there are only a handful of fonts that fit that bill.

Thankfully, that situation is changing. All modern browsers now support the ability to download web fonts. A web font doesn’t need to be installed on your local computer—it can be read directly from a web server and used immediately on the webpage that you’re loading. In May, we launched the Google Font API, which makes it easy for website developers to include any one of an ever-growing list of web fonts on their pages. We’re already using the new API for the latest themes in Google forms.

As of today, Google documents supports web fonts (using the Google Font API) and we’re excited to announce six new fonts.

Droid Serif and Droid Sans
Android fans will already be familiar with the Droid family of fonts. Droid Serif and Droid Sans both feature strong vertical lines and a neutral, yet friendly appearance. They’re designed specifically for reading on small screens.


Calibri and Cambria
Every day we have many people import documents from Microsoft Word into Google Docs. Today we’re making import fidelity better by adding two of the most popular Microsoft Word fonts. Calibri is a beautiful sans serif font characterized by curves and soft edges. It’s designed to be high impact. Cambria is built with strong vertical serifs and subtle horizontal ones. It’s very legible when printed at small sizes.


Consolas and Corsiva
Consolas joins Courier New as the second monospaced font in Google Docs. It’s a modern monospaced font with character proportions that are similar to normal text. Finally, Corsiva is our first italic font with embellished characters and an elegant style.


Right now our font support covers most Latin and Western European character sets. However, we’ll be adding web fonts for other languages (like Hebrew and Greek) soon. If you don’t see the new fonts in your documents, check that web fonts are supported in your language and that the document language is set correctly from the File -> Language menu.


This is just the beginning of fonts in Google Docs. We added six new fonts today and we’re already testing our next batch. You’ll see many more new fonts over the next few months. And because Google Docs uses web fonts, you’ll never need to install a new font: when you load your document, the latest set of fonts will always be there, ready to use.

Finally, adding web fonts is just one of the challenges that we have been working on. If you’re interested in learning more about the challenges of building a collaborative application, check out the first post of a three-part series on collaboration posted earlier today.

Posted by: Jeremie Lenfant-Engelmann, Software Engineer

Read More