I noted that you can't run a test until you first save it, even though there is a Run button. You may wish to make this piece a little smoother.
I got a little confused by the queueing though. Was I supposed to wait when it said queueing? I did, but nothing happened for a while. Then I selected the browser type again and clicked the button to run the test. This time I had my results.
My problem was that my application requires authentication - in particular Twitter OAuth. Do you have any plans to address authentication in general. I didn't know how to work around it, so I couldn't evaluate the playback.
I tried to leave a comment, but when I submitted it, the message came back "Not Found".
I started my search by looking at the providers that offered certificates accepted by Firefox and Internet Explorer. My next level of filtering was to look at cost and the ability to try the certificate for free during a trial period.
I settled on Comodo (instantssl.com). The evaluation period went perfectly. At the end of the period, I paid (I seem to recall $99) for a one year certificate. They required a couple forms of indentification (driver's license, utility bill) and the process went smoothly. I am using the certificate now at bigtweet.com.
I spent a lot of time at the beginning of my project (bigtweet.com) writing some unit tests in the Perl Catalyst environment. I think that it was very worthwhile at the time while I was changing structure, implementing exception handling, etc. Now that the project has stablilized and I'm mostly working on incremental functionality, I've largely skipped writing new tests (due mostly to time constraints).
I still run "prove" before any new release though.
I've also experimented with Perl code coverage early on with good success. Again, time constraints prevent me from pursuing this further for now.
If you have the time, I would highly encourage writing some unit tests for the core functionality.
The short URL is automatically created. If you check the checkbox "Automatically append short URL of current page" then the text area is automatically populated with this short URL. The same can be done for the web page title.
Give it a try and let me know if there is something else you are expecting or would like to see. You can reply to me @scott_carter
Doesn't it depend on what is behind the bookmarklet? In this case the bookmarklet is launching an application within the web page the user is browsing. Does it matter that the (BigTweet) application is "mobile" rather than at a fixed web site?
Granted, the current functionality is nothing that I would expect anyone to pay for.
As an example, what if the bookmarklet happened to open up a full featured word processor with all the bells and whistles? Not sure that you can say that the product wouldn't be worth anything just because the invocation happened through a bookmarklet ...
No, the medium is intrinsically wrong. Bookmarklets are easy to copy for free. Perhaps if your bookmarklet led to or interfaced with a fully fledged application, people might be willing to pay for the application - but then the bookmarklet is mostly irrelevant, or at the least is not the central appeal, much like del.icio.us's toolbar is omnipresent and yet not presented as the navel of the application.
I maintain - no one will pay for a bookmarklet, so a website that starts with "we provide a bookmarklet that..." is doomed to remain a hobby.
The page doesn't work very well without Javascript. In my opinion/experience it's better to create a page in a fully usable form without javascript first. Then write a nicer/flashier/*er interface in non-intrusive javascript ( i.e. not inline javscript on elements but in a seperate .js file )
Don't forget to include a friendly reminder "This page has features that require javascript" for the paranoid freakjobs who have javascript off ).
I see that you're pulling in:
Prototype - from GoogleAPIs,
YUI - from YahooAPIs,
Tab.js - from Uservoice ( Who I've never heard of )
As a Tinfoil hat wearing NoScript user that's alot for me click allow on and seems very messy.
Surely all the functionality you use/need/want could be provided by Prototype OR YUI ( or my favourites Mootools or jQuery )
On the design front. Please, please, please get rid of those Image Headings that look like they're from cooltext.com in favour of a Text Header and a Text Link. The Black Border around the whole site probably isn't winning you any friends and the text layout needs some fixing.
For the section about installing the bookmarklet I would:
Put a heading on it like "Get Started Now!".
Change the tense of "Help me" to "Need help installing?".
use a border/background-color/different font to separate it better, although a heading could do this.
Align the top of it with the top of something else.
Nice point about the page not working without Javascript - making it friendlier to those with it turned off.
UserVoice is a customer service site. I'm seeing it used more often and I really like the features. The JS for UserVoice on this page is for the Feedback tab on the right.
I use YUI for layout, buttons and tab controls. I don't think Prototype would help here - however perhaps YUI may have features that could cover the Prototype I use.
Ha! The logo was from cooltext.com Perhaps I need a disclaimer on the page saying that this page was designed by a programming hacker with no sense of style :)
You don't like the black border? That was one of the pieces I actually thought looked nice :(
I definitely got the hint though about the page being ugly. I agree. Please try the bookmarklet though. Of the 5 or so months of part-time effort, 99.9% went into the back-end and .1% on the front page. Yeah - guess I need a homepage facelift ...
Why so much time on the back-end? Catalyst had a big learning curve for me, and I was trying to design a flexible platform.
I agree on the ugly factor. A simple, temporary fix might be to center everything (after moving the "just drag.." text below the two subtitles near the logo). Some things are aligned left, some centered, doesn't flow well.
Also, the logo (specifically the font used) is very 90s. Pick something cleaner.
As I improve the application, would it be reasonable to mark some features as "pro", but not charge for them yet? The idea is to let users know that these particular features are free for now, but will eventually require a subscription.
I suppose I could include a checkbox to "enable" pro features rather than label them directly.
If you are going to charge for the features, you should not make them free, even to begin with. By doing so, you create an initial value in the users' minds of what those features are worth... $0. If anything, charge for the Pro features and gain a good user base (though you might not sell a single Pro account), and then have a one-day special where users can sign up for a month of Pro for free (or something along those lines). This allows them to get a taste of the Pro without eroding the perceived value.
You might also consider making the whole thing free and asking for donations to help you keep the project going and continue improving it and adding features.
As far as building a sustainable business goes, Twitter can't even do that from their own service. It will be difficult at best for you.
Would actually be interested in a co-founder. It's hard to get everything done by yourself :)