New Google Notes Feature: Automated Email Backups

Google Notes is now capable of performing automatic email backups; you can receive daily, weekly, or monthly emails containing snapshots of your notepad. This is useful in general for keeping archived copies of your notes, and in the event that we have any downtime, you can at least have a recent backup copy of your notes.

To activate automatic backups for your notepad(s), we ask that you donate $1/month or $10/year to support Google Notes. By donating (via the button in the column to the right), you help ensure that we can continue to provide consistent, long-term service.

If you are unable to (or choose not to) donate, you can still create backups manually by clicking the "backup to email" button for your notepad. However, the automatic backup option exists to ensure consistent archiving with no added effort.

To receive automatic backups, click the "backup to email" button for your notepad. From your email account, reply to the backup email. In the reply, please include your email address, category name (in quotes in the first line of the backup email), and the desired frequency of backup (daily, weekly, or monthly).


One last tip for anyone who uses email backups, it may be useful to add a filter to prevent them from filling up your inbox. In Gmail, to automatically filter your notes, take the following steps:

Near the search box at the top of Gmail is a link for "add filter". Click it and a small form should display. Fill in the "From:" field with "david.hoelscher+googlenotes@gmail.com" and fill in the "Subject:" field with "Google Notes Snapshot". Run a test search to make sure this picks up the right emails, and click next step.

On the next form, you will probably want to check "Skip the Inbox (Archive it)" and "Apply the label". You may want to create a new label like "Google Notes" so you can quickly pull up a list of your note backups. Click "Create Filter" and you're all set up and ready.

New Feature for Google Notes: Backup to Email

We're barely a day in, and 2007 already looks to be a good year. Fresh on the heels of the "full screen" feature, I've added a "backup to email" feature, which allows you to send a backup copy of your notes to your inbox. It's a step towards my goal of having automated backups, wherein your notepad contents are backed up to your email automatically on a daily/weekly/monthly basis, if desired. This not only lets you easily save your notes, but also lets you search through older copies of your notepad data.

If your notes aren't backing up properly, make sure you're checking the right email account. The notes are sent to the email address provided when you first started using the service. You can review this information by clicking "edit" in the top, right corner of your Google Notes. If you used some fake email address (which is perfectly understandable), then your notes will be sent to that fake email address. If you want to change the email address for your notes, you can either:

1) copy your notes, edit the email address, and paste the notes in the new notepad window

OR

2) use the buttons on the right side of this blog to add a new notepad (maybe you want to try a larger one?), fill in your email, etc., and copy over your old notepad contents.

If everything checks out and you still aren't getting your backups, feel free to let me know via email or a comment here. I've done my best to minimize the possibility of the email being marked as spam (by sending as plaintext instead of html, etc.), but we may have to feel our way around a bit before the system is flying right. Also, please let me know if you have problems with receiving multiple backups...that is, "click once, backup twice". I may enforce a minimum one hour (or so) spacing between backups to prevent accidental overload.

New Google Notes feature: Full Screen

• Full Screen for Google Homepage Users
• Refresh for Google Desktop Users
• Public Notepad in your blog or on your website
• Upcoming features
  

For those of you who have been able to put up with our recent server outages, you now have your reward (or at least a reward). The Full Screen button gives you a lot more room for your note-taking and note reviewing.

• If you use Google Homepage, this button will expand your notepad to take up the full browser window area. If you're like me and make heavy use of your notepad, this will come in very handy, freeing you of the (previously tiny) window constraints.

• If you use Google Desktop, this button will open a browser window to show your current notepad (if, for example, it has been changed via Google Homepage). I've had many requests for a refresh button, and I'm still trying to see if I can get it to actually refresh within Google Desktop.

I've also corrected a recent inadequacy with Google Notes: one of the unfortunate side effects of the recent outage was that the note save frequency was changed from every 1 second to every 10 seconds. This meant that you could potentially "lose" the last few characters you were typing if you closed your window too quickly. I've put in a nice fix for this--the note saving frequency is now every 5 seconds (to reduce server load), BUT if you close the window or navigate away from the page, it'll go ahead and save it anyway.


I mentioned before that a few of you have used Google Notes for a sort of "shoutbox" or "public notepad" on your blog. The new button makes this easy for anyone to implement, so here's how you can do it:

1. First, add a new notepad to your Google Homepage and give it an email & category combo (the buttons to the column on the right of this blog will add a notepad for you). Click save and then click the new button to expand the notepad to full-screen. Copy the URL at the top of your browser. (You can even bookmark it if you want to jump directly to your notepad in the future.)
2. In your blog/website template, set up an iframe pointing to that URL. You can paste the following code in your template and it should work (if you replace "foo.html" with the URL you copied in the first step):

<IFRAME SRC="foo.html" WIDTH=200 HEIGHT=300></IFRAME>

One last thing to mention about the new Full Screen button...after you click it you may notice "up_wordcount=" in the URL. If you change this to "up_wordcount=1", you can enable a rudimentary word counting feature.

The next thing I'm working on is a "send notepad contents to email" button, so you can look for that in the future.

Too much of a good thing...

is not a good thing. Don't get me wrong, good things can be good, but there must be some balance. Google Notes has been a bit unbalanced recently.

My brother Richard (who works part time for the local hosting company that allows Google Notes to exist) has brought Google Notes back online after about a week of downtime. Here's what he had to say about it:

"Everything is back online now. Technically, after replacing the server that Google Notes wound up killing, we had to find something better than mod-fastcgi for keeping the app online in between http requests. mod-fcgid works great for reqular loads and shared sites, not so much when there are 100 requests per minute. We deployed on mod-scgi instead, and it seems to be working fine so far."

Roughly translated: we had too many users and too little server.

I would personally like to apologize for the disruption in service--it was frustrating for many of you and myself alike. With that in mind, I've added a donation button for Google Notes. For starters I've just set up a Paypal thing, but if someone wants to use a different service, just let me know and I'll try to set it up as well.

There will be two main places the money will go: helping to cover the cost of hosting the service (and replacing servers we kill), and future development for Google Notes.

Two new features that I hope to have in place soon:


A combination refresh/full screen button. This will (finally) allow refreshes for those who want to sync up their notepads on Google Desktop--I've received several requests in this respect. Also, for those who use it on Google Homepage, it will expand the window to take up the entire screen. This is perfect for those of us who pack in a lot of information into their notepad.

The second feature is a "backup to email" button, which sends a copy of your notes to the email address you provided. During this last week of downtime, one of the Google Notes users suggested this and it seems (by far) the best way of handling user-accessible backups. I had considered "file->save" and cookie-based approaches, but this one is elegant and can even be automated for monthly/weekly/daily backups.


So there you have it...that's the plan. Feel free to donate as little or as much as you want (suggested amount: $2/month or $10/year). We'll still try to keep it online and keep improving it regardless of the donation amounts, but at the hosting company Google Notes has the unfortunate reputation of being the lowest income generator and highest traffic generator. Business-wise, it's hard to justify.

Also, I have considered (as an alternative) adding a small row of context-sensitive Adsense below the notes. Aside from taking up valuable real-estate, this detracts from the simplicity and cleanliness of Google Notes so I'm personally not in favor of it. If anyone has any comments regarding this (for/against), I'd like to hear them.

SVG Maps

For the last few months, I've kept the idea of SVG maps accessible from an internet browser in the back of my mind. The reason isn't so much for the technological challenges involved, but for a practical effect: I've been working predominantly from a 56k modem (which is maxes out at about 44k) dial-up internet connection. The major map tools out there (Google, Yahoo, and Mapquest) are intended for high speed connections. They reload new data for every zoom in/out, and it takes a full minute for maps to load, which is painful when you want to quickly check directions before hitting the road.

Using a scalable vector graphic (SVG) map would fix this pretty well. Most map features (except satellite images) are represented by lines or borders. These lines and borders can be compactly represented as a series of coordinates, which is precisely how SVG is done. SVG uses textual data in an XML format to draw all sorts of basic shapes, complete with fills, transparency, and a variety of special effects.

By leveraging SVG for online maps, we get several immediate results:
- Faster to load. Map feature coordinates would be sent to a set of client-side JavaScript functions which translate these into the appropriate SVG elements. This would require significantly less data transfer than the usual image files that are used.
- Faster to zoom. When you zoom in/out on an image based map, entirely new images must be fetched from the server. However, with SVG, only the "new" map feature coordinates must be fetched, as previous data can be reused from a different zoom level

One downside of this approach is that to use SVG, you need a newer browser that supports XHTML and SVG. Mozilla Firefox does this, and IE will do this if you use an Adobe plugin. On the flipside, this leads to another positive:
- SVG maps are ideal for cell phones and other embedded applications. One of the driving factors of using XHTML is that is simplifies a lot of things browser-side. By requiring XML well-formedness and other constraints, internet browsers get simpler and more easily integrated into things like cell phones. If we assume that cell phones of the future contain XHTML browsers, and that cell phone data transfer rates are always lower than that of a hardwired connection, it makes perfect sense to use SVG for map data (as opposed to using images, which are worse in terms of data size, flexibility, and reusability)

As for me, I've been playing around a bit with SVG and fleshing out a possible implementation strategy. The guys at carto.net seem to have a good head start on SVG mapping, but I don't see anything (so far) that seems to focus on creating a fully-featured map that offers things like driving directions, business searches, and so on. They do however, have some samples that show how to use JavaScript to interact with SVG, talk about browser compatibility, and they have some neat demos set up.

For the most part, I've set up an rxml file in Ruby on Rails using XmlBuilder that includes some SVG data. This way, I can easily integrate information from a database, minimizing the number of unnecessary headaches. Using the .xml extension, however, means that while it works in Firefox, it doesn't work in IE, because IE simply displays the content of XML files (regardless of the doctype). If I could get RoR to output files with the .xhtml extension (and no, .rxhtml is not recognized), there would be no issue, but I haven't gotten far enough or deep enough yet to make that happen.

Here's how I would implement my proposed map system:
- Create a database of all possible map elements, along with their coordinates. For long elements, like the Texas border, I'd break them down into smaller elements.
- Assign each element a unique ID. Order the IDs based on how "localized" a feature is. Basically, SVG documents are displayed so that the first element listed is painted on the screen first, so any subsequent elements occurring in the same area are painted over top of it. The last SVG element is the last to be drawn, so it will not be overwritten. By ordering the element IDs properly, we can establish the "drawing order" so we don't need to worry about a lake being drawn on top of a bridge.
- When the user accesses the map, the center screen coordinates and the zoom level is sent to the server. The server processes this information and sends the relevant data (to be displayed + some beyond visual extent) to the client. This information includes coordinates, feature type (interstate, country road, railroad, lake, state border, etc.), feature name, and the range of zoomlevels for which it should be displayed.
- The client receives this information and processes it (via JavaScript) into SVG data and stores the original XML. When the SVG data is added, it is added in order of unique ID for reasons mentioned above.
- During panning, zooming, or re-centering, a request is sent to the server containing the new coordinates and zoom level, along with the list of unique IDs already existing client-side. The server sends any new data that will need to be redisplayed on the map.
- The client processes the new data and the stored data and paints the displayable elements (that fit into the window and meet the withinzoomlevel requirements).
- Rinse, repeat, ???, profit

Note that business and address searches can also be handled dynamically in a similar manner.

One minor caveat to this whole thing is data accessibility. In my limited search for good map data to use, I've come up relatively empty-handed. I suspect that it costs quite a bit to get good map data, and I'm not at a point where I can pony up the money for something like that. I'm open to suggestions if anyone knows where this sort of information is available to the general public. Even if data were used from a vendor, it is possible that lat&long coordinates could be extracted from the SVG source, so there may be some needs for code obfuscation, which (ironically enough) is something strange enough that I haven't really looked into it before. befor

XPCOM Lisp (or XPCommon Lisp or XPLisp or Mozillisp or Mozilisp)

For over a year now I've had this idea of a lisp interpreter embedded in Firefox (or more generically Mozilla). It seems the more I think about it, the better it might be.

Presently, Mozilla uses Javascript as the "glue" between XPCOM components, XUL, and whatnot. Why couldn't Lisp (or some variant) be used as well? You could send some Lisp code to an XPCOM component and it interprets it for you, with access to other XPCOM objects. AutoCAD has AutoLisp...I would have a hard time imagining that a Mozilla equivalent would be completely useless.

To compound things even more, I found another reason why it might be good: the GUI. Lisp seems to be stuck (for the most part) in the text-based world...except for HTML applications and a few others. However, a Lisp XPCOM object could take advantage of XUL for buttons & widgets, which is handled quite nicely in a cross-platform manner. Indeed, with an XPCOM Lisp interpreter, the whole thing is cross platform...no porting necessary. One could even set up a Mozilla-based SLIME & Emacs editor (has this been done?), so the Lisp code creates Mozilla-based applications from a Mozilla-based editor & interpreter.

From what I know, it seems like there are two approaches to this method:
(1) Create a replacement for XPConnect that interfaces Lisp directly to XPCOM objects.
(2) Use the exisiting Javascript system to communicate with a Lisp XPCOM object by passing strings which contain Lisp functions.

I'm thinking (2) is a much better/simpler/more elegant solution, although there may be some limitations that I'm not aware of.

Are there any showstoppers in the idea, or is it just complicated/hard?

Why Paul Graham won't release Arc

Paul Graham recently posted some startup lessons he spoke about at the 2006 Startup School. In his writeup, he mentioned:

Perhaps the most important reason to release early, though, is that it makes you work harder. When you're working on something that isn't released, problems are intriguing. In something that's out there, problems are alarming. There is a lot more urgency once you release. And I think that's precisely why people put it off. They know they're going to work a lot harder once they do. [2]

If we look at the footnote, we find:

[2] I know this is why I haven't released Arc. The moment I do, I'll have people nagging me for features.

This tells us a few things right off the bat. First, Arc probably won't be open source. If it were open source, then it could be assumed that Paul's massive following of hackers would jump on it, fix up the rough spots within the first week or two, and proclaim it to be the next best thing since Common Lisp. If it were closed source, then yes indeed, there will be an equally large push to find bugs, during which, there might be some questions raised regarding Paul's hacker status and (in)ability to extinguish bugs quickly. He'd be right to harbor some concerns.

The next logical question is, why closed source? If he releases a buggy product built around well-designed concepts or constructs, then it probably won't take too much effort to implement a similar product in an open-source manner. Open-source products generally arise because their closed-source counterparts are (1) too expensive, (2) too buggy, or (3) both. We can certainly conclude that Arc v1.0 will be buggy, and it's anyone's guess as to whether it comes with a price tag. The interesting thing about open-source is that any price tag is too much.

There's also the question of competition. With the likes of Ruby on Rails in the neighborhood, I too would be concerned about delivering a competitive web-developing product. Even at that, Y-combinator is funding would-be Arc-competitors like Infogami.

Regarding the open-source question, the easiest defense is probably something along the lines of "We're hosting a server that will run (insert name here), so we don't need to release the source code". Certainly, this formula works well for Google and the Y-combinator startups. Steve Pavlina has written extensively about finding your purpose, and for Google and the startups, they have a purpose for keeping a tight lid on their source code. They want to keep their secrets to themselves, and they work hard to make sure their secrets are worthwhile.

What would be the purpose in keeping secret the implementation of Arc? I think it's clear that Paul won't enter "desperate startup mode" and code 12 hours/day to stay on top--not now and not ever again. Thus, any startup-type business model he builds will lack the key element of determination. We can scratch off any plans for making money (read: creating wealth) startup style.

Why can't the implementation of Arc be open-sourced? I don't know. There's nothing magical about server-side code that prevents it from being open sourced; heck, Apache is ALL server-side code, and it's used practically everywhere.

What is the purpose for creating Arc? If it is to enable hackers everywhere to use more powerful development tools, then there is a chance of it catching on if it's open source. If it is to help Paul Graham make more money, then it may never see the light of day.

Paul, if you read this, I hope you're feeling a little deva vu from when you made your "Ask wealthy entrepreneurs for money, but don't ask me." This time, however it's more along the lines of "Release software early, but don't ask me to release mine." Instead of nagging you in detail about it, I'll just say: number one!