Mike, wow...thanks for the offer. I re-launched my site as a paid service about a month ago. It is an online text editor for Dropbox. (I guess you can disregard this if you are not a Dropbox user).
I hope you don't mind temporarily shelling out $6, but I would really appreciate it if you could sign up for the service and answer a few questions:
- Is it clear how to sign up for the service on the home page?
- Does the signup/payment workflow feel straightforward?
- Is it clear how to get a refund? Is the process straightforward?
Hiya! Sorry it took a bit. (I've been fighting with taxes.) So...
- Signup: I was a little surprised when it sent me directly to Dropbox to signin. I thought it was an error, but realized it was asking me to signin so I could authenticate your service. Then I authenticated and was faced with your price. I don't think this is the right way to do it. I know you're trying to test the viability of your product (separate from your price) but I think there's more going on here.
First, you didn't warn me about a price with the exception of mentioning a "subscription" and a 7-day guarantee. Waiting until after authorization frustrates me because if I didn't want to signup, now I have to go back to dropbox and cancel my authorization there (instead of just closing the page and moving on with my life).
And even though you're using an inverted pricing model (subscription price grows with wide-spread use), you should use that to create a sense of urgency to signup faster instead of hiding it after authorization. Use demand to compel them to try sooner by showing the raising price up-front before they authorize Dropbox.
- Then there's the issue of permissions. Because the first experience with your service via Dropbox is "Give this random app FULL access to your ENTIRE dropbox." I think it's a lot to ask someone when they just want to edit their text files with your service. It could help if you prepare them before sending them to the authorization funnel with a warning/explanation screen.
+ The app is incredibly snappy and a pleasure to use.
+ The search bar is helpful even if it wasn't immediately obvious that it was search. I think it was easy to discover though. Maybe make it robust enough to support fuzzy search (a path of app/js/main.js could be found by searching for "appjmain") and masking (*? characters).
- PLEASE put some basic file handling functionality. (Delete, rename, move would be helpful...) Anyone editing dropbox text files will probably want these functions as well. (If they're there, I couldn't find them.) It also wasn't clear how to "close" a file aside from switching away from it.
+ Refund seemed to be cake. I'll let you know if I have trouble getting the funds back. (Big fan of stripe.js, too!)
Hope this feedback helped. And again, sorry for the delay.
Hi Mike, please, no need to apologize for the delay. I really appreciate you taking the time to look at this.
These are all great points, especially regarding the signup process and and permissions. I think you have validated some of the concerns that I have had regarding these issues.
I do have delete and rename, but maybe I should pop up a quick intro screen for first-time users to get acquainted with the functionality.
Using Node has helped me think more in terms of streams because the APIs afford such thinking. PHP has streams but I never thought to use them, and I haven't really seen it done.
Node Streams really help performance in my application where I am proxying API calls from the browser to the Dropbox API. It's much faster to stream the response from Dropbox through to the client rather than request, wait for entire response, then send.
I agree. I don't know about TCP behavior, but this seems really wrong in the sense that it ignores HTTP semantics of GET and POST. I imagine this could cause unintended effects in intermediaries like caching proxies.
1. backlog.txt - a list of all potential ideas and tasks
2. changelog.txt - a list of iterations/versions/milestones
Whenever I have an idea or bug, I add it as a line in backlog.txt
When I want to actually work on code, I pick 3-4 tasks that I want to complete and move them to changelog.txt. The number of tasks depends on how much I can do in one or two sittings.
backlog.txt is in a format like this:
* Fix IE9 compatibility
* Refactor CSS
* ... etc
changelog.txt looks like this:
1.1.0 - next release
--------------------
* Fixed IE8 thingy
* SSL encryption enabled
1.0.9 - March 10, 2012
--------------------
* Fixed null-pointer crash
* Catch exception in sendmail.java
* Enabled websockets transport
Keeping everything in plain text helps me from fiddling around too much with the tool, which I am very prone to do. (Meta-bonus, my product is a text editor so I can organize my product with itself.)
Thanks for this. What a simple concept! I have so many docs trying to manage myself that they have become almost unmanageable. I've been using Google docs, Evernote and Trello. I recently took to using Trello as an electronic diary.
Not to mention, I still scribble in an actual notebook!