You MUST say this on the website, otherwise, it's purely frustrating. My first thought was "how dumb", and you really don't want that. Had I known this was the reason, I would understand and try another browser.
It says that it's saving my work to local storage once per second. I do love having seamless backups of my deathless prose, but this seems like overkill to me. There are limits to how many brilliant thoughts I can type per second. Every ten to fifteen seconds is probably fine.
Mind you, I'm not the one who is going to have to debug this stupid idea cross-browser, so please forgive the suggestion if it turns out to be stupid. ;)
I believe that onbeforeunload always prompts the user with a popup, which may be why I left it out -- can't quite remember. I will re-evaluate that decision.
Being able to set the timeout would be a nice feature. Really I would be annoyed with 15 seconds, though I do agree that such a timeout is more suitable than is 1 second. I keep my hard-drive spun down for a simple reason: power consumption. I suppose I could dig around and find out why Chromium is being forced to sync against my explicit fstab timeout, but that's rather too much effort. Besides, electronic data is impermanent; I must either trust that my browser maintains the local storage correctly or that you do on your end. The matter of convenience of such an electronic journal--say over my Moleskine or org-mode setup--is that I am spared a bit of setup cost. In turn I trade a bit of peace-of-mind with regard to my data.
Simplicity -- Just one entry per day, automatically time stamped. Security -- Your entries are encrypted using JS before being sent to the server, so I, as the sysadmin, can't read them and harass you as some google employees are known to do.
Don't you as the sysadmin have access to the keys though? Even using an evercookie or something like that -- I fail to see what prevents you (Your malicious twin lets say) from seeing these?
The key (which is generated from the password), is stored using localStorage while the user has the app unlocked. I could certainly send myself the key somehow, but the concerned user should be able to snort that out fairly easily. I guess one option would be to opensource all or part of the js.
I'm interested in learning how this works. i.e. how do you encrypt the data client side? is it a randomly generated key? (I guess not since the user would need to know it to decrypt the data on another machine). If the user picks a key, is it the same as their password? If the key is the same as their password, do you store the password in localStorage? etc etc?
(Sorry, just thinking out loud here and not sure how this'll work)
Got it. On security, you might try and test to see whether the added security you offer is meaningful to your audience. The security offered by web services is already sufficient for me to share my most personal emails and financial information.
I like the idea of a simple beautiful interface where I can look back at my journal entries easily.
Super simple. It just works. Given that it's a journal, it might be worth thinking about how you would suggest to users that this service will be around for longer than a few months, or how they can export their data to another service in the event that this goes down. I wouldn't want to start keeping a journal on a site that may be gone tomorrow.
I went to click the "Sign In / Sign Up" link. It turns out that these are two links. The visual design and wording had led me to expect otherwise: They're sort of close together, and worded with that alliterative wording and the slash in between, and not distinguished by color or design.
Then, worse, I didn't have a link from the "Sign in" page to get to the "Sign up" page. Even the classic, cheesy "if you do not have an account yet, please sign up" sentence would have been welcome.
Fortunately I know about back buttons. But it is still a small rough spot in an otherwise silky-smooth design.
I'm not much of journaler, but I think the execution is excellent. Only suggestion: include OpenID or OAuth option for sign up and sign in, so you can have single click access if you want your own account. Should help keep that streamlined feel.
A small suggestion: allow for European date formats, or change the date format so it is not ambiguous (10/1 = 1-Oct or 10-Jan?). Non-US users get their knickers in a knot about things like that. Especially when they later want to sort the data.
35 comments
[ 8.4 ms ] story [ 27.5 ms ] threadMozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/534.3 (KHTML, like Gecko) Chrome/6.0.472.59 Safari/534.3
Please do email me if you'd like more details.
http://stackoverflow.com/questions/138411/catching-a-tab-clo...
Mind you, I'm not the one who is going to have to debug this stupid idea cross-browser, so please forgive the suggestion if it turns out to be stupid. ;)
Not, of course, to besmirch your efforts.
(Sorry, just thinking out loud here and not sure how this'll work)
I like the idea of a simple beautiful interface where I can look back at my journal entries easily.
Then, worse, I didn't have a link from the "Sign in" page to get to the "Sign up" page. Even the classic, cheesy "if you do not have an account yet, please sign up" sentence would have been welcome.
Fortunately I know about back buttons. But it is still a small rough spot in an otherwise silky-smooth design.