I ran across a book titled Web Form Design: Filling in the Blanks by Luke Wroblewski which, according to glowing blurbs from well known folks, a great book on web form design. But, when I proceeded checkout after placing the digital copy in the shopping cart, this web form smacked me in the face:
While the form may be clean looking and arguably well organized, it made me abandoned the purchase. Why do I need to create an account with two-book publisher website to purchase the book? If the form was optional and discount was offered in exchange, I might have thought about it but not if it’s a requirement without a matching reward. I also didn’t see why they needed my address when I am buying a digital copy?
The lesson here is:
Web designers should first justify, from the customer’s perspective, the need for each form and its components well before sculpting them into perfection.
If you are not a geek, sorry about these tacky-techy posts. I like posting them to help others geeks running into same problems later.
I’ve been running my GAE apps locally on my Mac using Google App Engine Launcher. The tool makes it simple and easy to develop and test apps designed to run in Google’s App Engine cloud but I ran into a problem when I tried to test my apps with Internet Explorer (running locally in VMware Fusion). Basically IE couldn’t see my apps.
After a few minutes of googling and poking about, I concluded that GAE Launcher was binding my apps to loopback IP (127.0.0.1) instead of an external subnet IP (192.168.0.x). The fix was simple:
Stop target application
Open its application settings dialog by double-clicking on the app in the list of apps.
Add to Extra Flags box: –address=192.168.0.x
Start target application. If you have firewall on, you’ll be asked to allow Python.app to accept incoming connections.
Other options for GAE Launcher are:
--help, -h View this helpful message.
--debug, -d Use debug logging. (Default false)
--clear_datastore, -c Clear the Datastore on startup.
--address=ADDRESS, -a Server binding address
--port=PORT, -p PORT Port for the server to run on.
--datastore_path=PATH Path to use for storing Datastore
file stub data
--history_path=PATH Path to use for storing Datastore
--require_indexes Disallows queries requiring composite
indexes not defined in index.yaml.
--smtp_host=HOSTNAME SMTP host to send test mail to.
--smtp_port=PORT SMTP port to send test mail to.
--smtp_user=USER SMTP user to connect as.
--smtp_password=PASSWORD Password for SMTP server.
--enable_sendmail Enable sendmail when SMTP is not
--show_mail_body Log the body of emails in mail stub.
--auth_domain Authorization domain
I’ve been busy crossing the deep jungle of chores that suddenly appears whenever one attempts to launch something. I’ve also been using Twitter whole lot more, partly to test but mainly because the service I am building brings services like Twitter way too easily accessible. It’s the phenomenon I’ve been trying to confirm but, now that I have, I can see how it needs to be leveraged carefully to avoid exposing users to addictive and, potentially, career ruining behaviors.
After recent announcement of new Twitter API limits followed by news of Twitter seeking funding at $250m valuation, I think Twitter may be building a double-prong business model: one they are still trying to define and a platform business model that charges businesses for web services for near future and, later, hosted services (run sandboxed third-party code at Twitter for tighter.
As a company, Twitter is still trying to come to grips with its identity — whether it wants to be a service, a platform, or both. If it is just a service, then a $250 million valuation might be too rich. On the other hand if it ends up becoming a platform that is supporting add-on services such as Twitpic Stocktwits, then it can be accorded a different valuation.
I don’t think Twitter has to, nor should, choose one or the other if it can go after both. Of course, that takes time and resources as well as creativity and control but I think $250m valuation will help.
Speaking for myself, I am fine with paying for Twitter’s consumer service as well as platform service as long as fees are reasonable and service is flexible and dependable.
To other Twitter developers and entrepreneurs, a word of advice: try working within what Twitter API is designed for instead of trying to force it to do what you want.
Cool or not and needed or not, not everything that can be built should be built.
Yesterday, I went over to checkout Google App Engine and, because GAE made it so easy, ended up writing a little webapp I’ve been thinking about writing for a while. Besides, it’s been a while since I used Python so any excuse would have worked. Currently, it runs only on my laptop because I haven’t added security bits yet but it shouldn’t have any problem on the real thing.
Oh, shit. My MBP’s video memory seems to be on the brink. I am getting random lines on-screen now.
The app is a port/extension of part of the Twitter client functionality I had in Appily, my AIR client from more than a year ago that I shelved before starting SafePage. It scratches a usability itch that prevented me from using twitter more frequently. I wrote it to see how improving accessibility radically affects usage patterns. So far, it’s working but more time will tell.
What I found frustrating while coding for GAE are the usual constraints of sandboxing but, for languages with rich third-party library support like Python, it gets really bad because many of those libraries have to be rewritten or replaced to varying degrees. For example, I couldn’t use existing crop of Twitter client libraries so I had to code the necessary calls myself. Each such incident is no big deal but the difference between hastily handcrafted code and libraries polished over time piles up.
Anyway, it was fun. Hopefully, I’ll still be in playful mood this afternoon so I can add the missing security bits and let others play with it too. Be warned, it’ll be rough as concrete floor as I don’t have the bandwidth to apply normal furnishings over the gears. My intention is to keep churning out snack-size apps like this one until one of them gains some traction then dig-in to see if it has legs, conversing with the users all the way.
Call it, conversational entrepreneuring. 😉
Update: Wonderful. Just in time to catch the newly arriving short–end of the stick. I can understand why Twitter is doing this. They are riding a tiger that’s moving faster and faster, trying to turn it into a golden goose without getting eaten. The problem is that it’s neither impossible nor easy. I say, Hi Ho Silver!
Still undecided about deployment strategies, I looked around to see if there are solutions like Aptana Cloud for Java, preferably with Eclipse support. Unbeknownst to me, Java cloud support started to bloom while I was busy wriggling over SafePage’s fate late last year.
Notables are Stax Networks (TechCrunch mention) which is a service (just got the invitation code) and CloudTools, an open source tool by Chris Richardson of Cloud Foundry that makes it as simple to deploy a webapp cluster as writing a Groovy script. A common trend I noticed is moving away from using AMI as unit of change to using script to modify base AMI image on the fly. Also RightScale’s CentOS 5 AMI image called RightImage seems to be quite popular.
Are there any other Java cloud services or open source projects I overlooked?
Update: Stax uses a command-line tool with a handful of webapp template types to create and deploy. I’ll have to dig in deeper into templates to see how flexible it is.
Update 2: g-Eclipse also looks interesting. I am going to dig into 1.0RC1 release last month and play with EC2 and S3 connectors. I also found Typica and jets3t which can be used to build a custom cloud deployment tool in Java if need be *eyeroll*.
Update 3: My conclusion for the day is that Aptana Cloud stands alone as end-to-end solution so far although others are catching up fast. Note that Aptana Cloud is essentially a cloud reseller, focusing more on development and initial launch phases of startup where companies like RightScale seems to be focusing more on post-launch operational headaches.
In case you haven’t noticed, I am back to my usual daily blogging habit since I now have more time to chase my own tail. That means I’ll be sticking my fingers into other people’s business and ranting pointlessly like I used to before. Hurrah!
Before I start prototyping some of the ideas I’ve been kicking around, I need to decide which tools I’ll be working with, making choices that’ll haunt me for months to come, as usual.
At SafePage, we started with the assumption of using Java because that’s what everyone had most experience with. Eclipse was also a hard addiction to break from. I tried to get the team to play with Groovy but, in the end, Java was it. This time, I’ll be the only coder for a while so I can be flexible.
At SafePage, we started with jQuery + Ext on my recommendation but discarded Ext within first few weeks because engineers found Ext awkward to use. Much later, we started missing sophisticated layout and table support both Ext and YUI offers.
This time, I am going to go with jQuery 1.3 (released today!) for most tasks and use Ext when complex widgets are needed since I personally had no problem using Ext. Quality and selection of Ext widgets is hard to beat but it’s too heavy for mundane Ajax stuff and style-conflict will create problems later unless Ext style is embraced fully which I am not willing to do. YUI style is cleaner but, egads, verbose YUI API really rubs against my simpletonian vanity. Re Dojo, I’ll just say it’s too liberal for my taste.
I like the choices John Resig made with both design and implementation so far although quality of most jQuery plugins and widgets are too brittle and selection of widgets too skimpy despite the size of jQuery developer community. I think it’ll take another year before jQuery UI widgets mature in substance, style, and selection. Note that both jQuery and Ext can be used in AIR apps which is going to be important later.
Adobe has concluded that ads in PDFs don’t work (via TechCrunch). I agree that normal ads don’t work but the general idea still remains largely unexplored. One variation I think has more merit augments PDFs and e-books in general with helpful context-relevant links.
For example, a PDF report on recent stock market performance could have a sidebar that displays a list of links sorted by relevance to contents of the page displayed. Business model for this variation is the same as yellow pages which sells ad-spaces around fine-grained content with tight contextual constraint.
The key difference between the original idea and this variation is that the original idea attempts to leverage primary content directly where this variation attempts to raise the value of secondary content (page relevant links in sidebars) within which ads are weaved in appropriately.
I just noticed that my ring finger is longer than my index finger. Hmm.
In a study of 44 London traders, the most successful tended to have longer ring fingers than index fingers, a ratio linked to high prenatal exposures to androgen, a male sex hormone. This exposure in turn is believed to increase adult testosterone levels.