Social Software

A design gripe…

I’m loath to complain in public about a service that I love so much, but I do not understand why’ submission form doesn’t limit the amount of characters that you can input into it. Instead, you’re left to work out later that whatever you’d written had been cut off automatically at a couple of hundred characters to fit into the database. This must be the simplest thing to fix, surely? I can only assume there’s a good reason for not fixing it that I’m missing. Can anyone help me out here?

16 replies on “A design gripe…”

I totally and utterly agree. It infuriates me that I have to keep checking my entires to make sure that they’re the right size, when I could have just known when I typed it in.
Couldn’t you chat with some of your Yahoo! elders and ask them to sort it out?

The length of the description field in delicious is 255 characters.
This is 2^8-1, the largest representable unsigned integer in a byte of storage. If each character takes a byte of storage under MySQL (i think this is true), then 255 is the number of characters you can fit in 2KB of storage.
This means that delicious *most probably* uses a VARCHAR 255-length field to hold descriptions. I would do the same, since it keeps the size of your database down, particularly with a data arch as big as delicious’. VARCHAR doesn’t null-pad entries – it’s not a fixed size. This alone could save delicious a huge amount of space.
To answer your question – yes, it’d be piss easy to add some DHTML/js code to cover this limitation . Someone could do a greasemonkey script. I personally can’t be arsed though, since my descriptions rarely get more descriptive than ‘yeah wow’ 🙂

Yeah – I just sent Anil an e-mail pointing that out, but thanks to both of you for the comments anyway: “Well yeah, I figured it would be around the 255 character mark, and I understand the limitation in terms of databases. I would have thought, though that the simple addition of a maxlength=255 attribute would probably fix the problem. js/dhtml be damned!”

This sounds like it could be caused by MySQL’s single most horrible feature – if you insert a string that is too long for the column it SILENTLY truncates the string (rather than raising an error). Apparently there’s a “strict” mode in the most recent MySQL but I don’t think it’s in widespread use yet.
This is the principle reason I switched to PostgreSQL 🙂 Sadly MySQL has much more mature replication support so for sites like you’re more or less stuck with it.

I think it’s so if you highlight a long passage and post (or cut and paste in some text) you have some manouvre room to edit it, rather than being truncated straight away by the field.
Should probably warn you before submission though.

They couldn’t just add a maxlength attribute, because the “notes” field is a textarea, and maxlength attributes are only for input fields. So doing what you want would require a smidgen of Javascript, rather than a dash of HTML.

I was going to say the same thing, Phil — until I realised that Tom’s initial comment was about the description field, which is presented as an input box, and so could have a maxlength attribute applied.

Chris: I’d rather know straight away if my copy-paste block of text is over the char limit. It’s much easier to copy more text from the original page before submitting the link than editing the link description afterwards. The simplest way of letting the user know if this will happen prior to submitting is by the maxlength attribute. I don’t know about you, but my brain isn’t very good at calculating what 255 chars should look like, even when the browser is using a fixed-width font.

I’m releasing a new version of Pukka today that helps with this. The idea is provide the fastest interface for posting to, with some little helpers along the way such as this.

Little late on the post, but I just found it a couple days ago while searching for clues on this limitation. Anyway, I’ve just released a new version of Pukka that helps with this. I’d appreciate any feedback you have (if you’re on a Mac, of course).

Comments are closed.