Leah Culver's Blog

Log in or sign up?

"Sometimes I put my log in information into the register fields."

"Me too! I hate that not only do I feel stupid, I have to retype everything again."

For one of my side projects, Leafy Chat, we have just added the concept of user accounts. This includes the need for registration and log in (as well as log out and forgot password and so on). Leafy Chat only requires an email address and a password for both registration and log in, so it would be great to have some clever way to have both forms on the homepage.

Some things to consider:

• Users only need to register once but will log in many times.
• It's really important to get new users and registration should be dead simple.
• Users will accidentally use the wrong form and should not be punished by having to re-enter their information.
• The two forms, register and log in, require different validation. For log in, we need to check if the username/password combination is valid and for registration we need to verify that the email address is unique.

Another project that I've designed also has an email/password registration system. Hurl is a site for testing APIs. At any point while using Hurl, a user can click the "Log in" link to log in or register. A pop-up displays a single form and two buttons to choose from: "Log in" or "Sign up"

I like this design because by clicking the correct button, the user determines which validation to perform. For example, if the user clicks "Sign up" and the email is already in use, they probably already have an account and can simply click "Log in" to correct the action. What if the user first clicks "Log in" but doesn't actually have an account? They simply get an error message that the account doesn't exist and can click "Sign up" to create one. The user isn't punished for picking the wrong form.

I think the Hurl design is an improvement over a two-form system but it's far from perfect. I don't like that the buttons look so similar and that there's very little guiding the user to pick one or the other.

Mike Malone suggested taking a look at Amazon's log in/register page. Wow.

I love this form because it is so straightforward. If you're an existing user, it's only one step to log in. For a new user, the form takes you to a second page that asks you for a little more information and also prepopulates the email you entered.

The use of radio buttons makes it clear that there are two distinct validation choices (as opposed to the form buttons which don't necessarily imply that you should only pick one). While radio buttons aren't the trendiest HTML form input, they are the appropriate one for prompting a user to pick one option out of many (while not obscuring the options like a select input does).

So after probably far too much research, I've come up with the following single register/log in form for Leafy Chat.

Log in

 

Sign up

 

The form updates via JavaScript when the user selects a radio button. For the log in form, notice that the submit button says "Log in" and there is a link to retrieve a forgotten password. For the sign up form, the label for the password field prompts the user to "Choose a password" and "Sign up!" while also accepting the terms of service.

I like this design because a user can either log in or sign up directly from the homepage and the radio buttons stand out and make the options clear to the user. I love that the page dynamically updates to provide relevant help for the chosen form. Also, the user can easily correct any errors without re-entering their email/password.

What do you think?

410 Gone

I've heard that Geocities is shutting down today. The very first HTML I ever wrote was for my Geocities homepage and now it is gone.

It's been almost a year now since my first web startup, Pownce, a social blogging site, was also shut down. Turning off a website is full of emotional issues as well as technical ones and it certainly isn't something I prepared for when I started the site.

The active users of the Pownce were my biggest concern. Before we took Pownce offline, we made sure to let our users know what was happening. We also gave them the opportunity to export their content and possibly reconnect the community on other websites such as Vox and Ning.

However, the Pownce community will never be the same and that is a real tragedy.

I feel it is rude to assume, as site users, that we fully understand the decisions that the site owners made. Yes, it costs money and more importantly, it takes effort to maintain a website. Even if the site is no longer dynamic, someone still has to make sure the servers are running and the pages are loading.

What about permalinks?

Links are the glue that holds the web together. What happens when those connections are severed? Isn't it annoying that a bunch of links will break? What about bloggers who linked to those pages? What about Google indexing?

I think the term "permalink" is misleading. Nothing in life is ever really permanent.*

As more people participate online, we need to get used to the changing nature of the internet. It's no longer about a bunch of static documents connected by links. Our profiles and statuses will update, we will friend and un-friend, and occasionally we will suffer loss.

I've suffered a lot of internet loss. I have a tattoo designed by Why the Lucky Stiff, a hacker and artist who this year, simply left the internet. Even my Twitter background image is from a long-gone web comic.

So things change, including the internet, and all we can say is "sorry for your loss" and all we can really do is move on.

Even the HTTP protocol has an appropriate response status code: 410 Gone.

* Except for death and taxes.

Hurl is now open!

Hurl is now open source!

Chris Wanstrath and I originally developed Hurl for the 2009 Rails Rumble where it won Most Complete. The idea was to create a simple web version of cURL, a command-line tool often used to test web APIs.

Hurl is super easy - just enter a URL and any extra parameters such as HTTP headers, body parameters, and authentication and then click "Send." You'll get the response and can save and share it.

By open sourcing the code behind Hurl we hope that other developers will be able to build on the concept. One very requested feature is to create an embeddable version of Hurl that can be used in developer documentation for easy try-it functionality.

Check out Hurl:

• Hurl
• Project homepage
• GitHub
• Twitter
  

Help us make Hurl even better! Patches welcome.

TypePad Motion

Today at Six Apart we released Motion, the project that I've been working on for the past year along with Six Apart's open source team.

Motion is a new microblogging platform that can be used to create community sites.  As a member of a Motion site you can post content such as messages, photos and video and participate in discussions around that content. Check out the Metric, Ryan Star, and Zachary Quinto communities to see how fans are using Motion to keep in touch.

I'm also excited that we have released the Motion code as open source. As a developer you can create your own community site with an unlimited amount of customization. Motion is a Django application with a few underlying Python libraries that interact with TypePad as a datastore (via the TypePad API). Motion also supports OpenID login and the OAuth authentication open protocol.

Since Motion is build on the TypePad API, you can also use the underlying libraries to create some other unique kind of publishing site built on TypePad. The libraries are very modular, so you can pick and choose the pieces you need for your specific project.

You can get started here on our developer site.

For good measure, here are all the links to the libraries on GitHub:

• batchhttp - Parallel HTTP through MIME multipart encoding.
• remoteobjects - An object RESTational model.
• python-typepad-api - A TypePad API client library for Python.
• typepadapp - A helper Django app for making TypePad applications.
• typepad-motion - Community microblogging on the TypePad API.

A big thanks to the Motion and TypePad API teams!

I'm totally into CSS

A couple of nights ago, while out with other DjangoCon attendees I exclaimed, "What am I really into right now? I'm totally into CSS." They looked at me as if I had said that I loved the audio quality of cassette tapes.

Yeah, I'm kind of into CSS and it's limited functionality.

I think a common mistake that we programmers make is that we assume that more functionality is always better. Kind of like, "What if someone wants to do x? Then we better provide the ability to do so!" While in reality, nobody is currently doing x and adding x creates an unnecessary rule that will need to be maintained.

The beauty of CSS is that it's so simple and has so few rules. In fact, I don't know how they managed to keep programmers from messing it up for so long.

My pal Jon Rohan passed along this great article about generally discussed features for new versions of CSS. Some of them I could see being very useful (variables, basic math), while others I find a bit too much like that aforementioned x.

Right now I've been finding lots of tools to help with my exploration of web design and CSS. The most useful tool is definitely the "meyerweb reset" stylesheet followed closely by the Firebug Firefox extension and ReCSS bookmarklet.

The Real Real-Time Web

Chris Wanstrath gave a great presentation at DjangoCon this week about The Real-Time Web. Since working on a web-based IRC client (yay Leafy!) with Chris and Alex Gaynor, I will whole-heartedly agree that the interesting part of The Real-Time Web is more about the browser than any backend processes.

Check out Chris' slides to get a better idea...

The Real-Time Web (and Other Buzzwords)

View more documents from err.

When I first saw the slide with the orange dude reading RSS on the toilet (around slide 12) I said to Chris,

How did you know I read my feeds on the toilet... using my iPhone... at work... at Six Apart??

New blog on TypePad

With the addition of the new minimalistic Pico blog designs, I finally decided to move my blog from a hosted WordPress install to TypePad. TypePad was an easy choice (not just because I work at Six Apart but) because I really wanted some simple post management tools, a GUI compose, and a nice design without having to do much work.

A few folks have asked about using a hosted blog service as oppose to using my own software, hosted on my own server. Truthfully, I'm just not that interested in writing or maintaining my own blog software at the moment. Maybe some day...

I've also moved this blog to blog.leahculver.com (in case I have some grand plan for leahculver.com some day) and have redirected all my blog links, so as not to break the web.

A is for Ajax and C is for Comet

There's a bit of buzz going around about the "real-time web" lately. The real-time web is about information delivered to the user as soon as it is available. Real-time notifications are exciting because it allows web pages to be more dynamic and seem more alive. These techniques also allow developers to mimic desktop applications, with their immediate user feedback, on the web.

With all the talk about "real-time" it's important to take a step back and evaluate the techniques we use to accomplish these browser feats.

1) Ajax (Wikipedia article) Ajax is the technique where a user action (via a web browser) is able to update information or retrieve additional information from the web server. I won't get into too much detail because Ajax really is everywhere these days. Favorite a tweet, digg a story, move around in Google maps, post a comment on Facebook... these actions are all performed via Ajax. You, the web user, take an action in the browser and the server is notified of what you did - no web page refresh required.

2) Comet (Wikipedia article) Comet is the lesser known of the real-time techniques and can be thought of as the reverse of Ajax (well, actually Comet often uses Ajax, which I'll explain later, but bear with me for now). An event happens that is known to the server and the server notifies the browser, updating the web page that the user is viewing. Again, no page refresh required.

The important difference between Ajax and Comet is where the action originates. With Ajax, the action is taken by the user and with Comet, it's an action from the server. Currently Comet is a popular technique for browser-based chat applications since it allows the server to receive a message from one user and display that message to another user. Some web applications that currently use Comet are Google's GTalk, Meebo's chat, and Facebook chat.

From a technical perspective, Ajax and Comet differ in the expected length of the request. Ajax uses a quick request-response to update or get new information from a server, while Comet typically opens a longer connection to get information as it is available from the server.

So how does Comet actually work?

There are several ways to implement Comet but the most common is called "long-polling". Long-polling means that the browser opens an XMLHttpRequest to the server but instead of expecting a quick response (like Ajax does)  the connection just waits. If the connection gets a response from the server, it returns that to the browser right away. Otherwise after a bit of time the connection dies and the browser sends another request and waits again.

How is long-polling different from just periodically checking with Ajax?

Some web applications, such as 37signal's Campfire chat application, use periodic Ajax (quick) requests to check if there's a new action from the server. The problem with this kind of short-polling is that it's difficult to tune to get the best results. For example, if you check for new stuff on the server every 5 seconds, what happens if a new action appears right after the response returns? Well, your user waits another 5 seconds to see that action. That's okay, but not ideal. Also, a lot of Ajax requests will be hitting your server when there is no data available and may waste more requests than having fewer, longer connections.

What's the future of Comet?

The heart of the internet is communication. The next generation of web applications will not only need to be responsive to one user, but also facilitate speedy communication between many users. The quicker we can chat, message, poke, tweet as well as see and respond to these actions, the better!

For more information on Comet, the Comet Daily blog is a great resource. The most popular library for Comet right now is Orbited. We use Orbited plus Twisted IRC for Leafy Chat, our simple web-based IRC client.

My own server

It seems like a silly thing to write about but I love having my own server.

In the past year I got my own Media Temple Dedicated Virtual server to use for side projects (mainly Baconfile). Since I'm an application developer (and not much of a sysadmin) I never really thought about managing my own web server. Surprisingly, I'd now say that my server is my most fun toy.

It's incredibly fun because I can have an idea for a web site, build it, and get it out on the web... all by myself.

Okay, so I'm sure some of you old-timey web programmers have been doing this forever, but not me. I've always relied on someone else to host my stuff (employers, cloud services, umm...ex-boyfriends) thinking that it was something that I could never manage to do (or really want to do).

Ha! Everything I've needed to know about website management is on the web and available via a quick search. In fact, it appears to be the most documented thing on the web! I like to imagine in the 90s people said "here's my document and here is how you're seeing it on the internet!"

Why bother mentioning this on my blog? I only say this because I know quite a few web developers who don't do their own hosting. I say to you developer friends - do it! It's the best thing I've done all year.

Web Product Guildelines

I've been keeping a gist of web product guidelines for myself. It's pretty much a list of stuff I tell entrepreneurs when they asked me what I've learned from Pownce  (from a product point of view) and also what I try to remind myself when working on new projects. I thought I'd re-post them here for fun. If I'm missing anything, be sure to comment.

http://gist.github.com/132292

I'm very interested in improving my product development skills, but I don't really where to go to learn more. Any suggestions?