Rate my App HN: Minimal daily journal app. Just start typing.(motodiaryapp.com)
motodiaryapp.com
Rate my App HN: Minimal daily journal app. Just start typing.
http://motodiaryapp.com
35 comments
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.
Seems to force my hard-disk to sync every half-second. Not so very desirable on a mobile device. For reference, I am:
Mozilla/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.
Mozilla/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.
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.
I hear you guys. Just trying to avoid the situation where you type something, then close the tab shortly thereafter and lose what you typed.
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.
Not, of course, to besmirch your efforts.
Not, of course, to besmirch your efforts.
I said to myself "man, isn't there a way to catch the tab close event in JS"? And, lo, Google provides:
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. ;)
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. ;)
And a Jquery specific question/answer, as I note that our friend is using that library: http://stackoverflow.com/questions/1631959/browser-window-cl...
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.
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.
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.
Could you explain what you see as the value over something like a google doc. Not trying to be negative, just curious where you see it going.
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.
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)
(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.
I like the idea of a simple beautiful interface where I can look back at my journal entries easily.
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.
So if I blow away my local storage I'm hosed?
Doesn't sound like it. The key would probably be regenerated from the password and stored in localStorage again.
I dig the UI. Very clean.
FYI for those of you who are curious how many hits you get from a post like this: 816 so far. (posted 2 hrs ago).
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.
I clicked "Try now", it didn't asked for my email. YES!
What about putting the front page as the initial content of the journal, and skipping the "Try now" part?
You could have the initial text all highlighted, so after reading the user can literally start typing.
Not a bad idea. Might be more engaging.
Your use of browser detection scripts frustrates me. You should test for features instead if you want to get conclusive data.
Maybe shrink the vertical space a bit so the "try it now" button is guaranteed to be visible without scrolling..
Also, support Firefox.
Will do :(. Right now there isn't great local js storage support in FF.
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.
Anybody have suggestions as to how to market this app?
A tiny, tiny nitpick - it's 'no one', not 'noone'.