Tell HN: Thank you for interface change | Hacker News Reader

Tell HN: Thank you for interface change

32 pointstokenadult18 comments

I've noticed that in the old days here on Hacker News that if I submitted an article with its original title (which is always the preference here) and the title was long, the error message would just tell me that the title had to be no longer than 80 characters. Now when an article is submitted with a longer title, the error message helpfully announces how many characters are in the title as submitted, helping all of us know how many characters to trim out of a title to make it fit the forum software limit. That's a helpful change. Thanks. Maybe in discussion here, if you please, we can list any other recent interface changes we have noticed.

View on HN

    <script type="text/javascript">document.getElementById('title').onkeyup = function(){document.getElementById('warning').innerHTML = this.value.length > 80 ? this.value.length + ' / 80 maximum characters' : '';return true;};</script>

Requires setting an "id" attribute on the title input field and then adding another element underneath of it with a "warning" id (<br><span id="warning"></span> works nicely).

Search. Not sure how recent it is but it's great.

Agreed, but think the positioning of it isn't useful - why not up top?

I hadn't even noticed it was there until now! It looks nice down there, just unexpected.

Hi Macu,

I'm replying to a comment before about Helperifix. As far as i know, the project is on hold. I know the guys, this is my email if you want to find out more info: lukejamesfitzpatrick@gmail.com

Probably to limit the amount of use it gets. Search is expensive (in terms of resources that it costs Algolia rather than money).

I miss the old search. You could do stuff like "this" OR "that". I had a bookmark of search with different subjects I was interested in.

Hm. Why don't they just limit the # of characters that can be typed in the title text box?

If I had to guess, so that the user can decide which parts to keep, based on the entire title. If they submit it via a bookmarklet, and the beginning of the title is "Some Corp Offical Blog | Mission Statement Blah Blah | Announcing The Worlds First" - you get nothing of value.

I'm not them.

But maybe because when you paste a value longer than the max it just chops off the end. That sounds good until you consider that the ultimate goal is to have people re-structure their titles to fit the constraints as best they can rather than just providing a "preview" of the content (e.g. first line of the content).

For example I may paste in:

> LambdaLite: A functional, relational Lisp database written in 250 lines of Common Lisp

That's 87 characters. It would get mangled to this:

> LambdaLite: A functional, relational Lisp database written in 250 lines of Comm

So now the person entering the title has to paste it into notepad, fix it, and then paste it into HK within the length requirements. That doesn't help anyone.

Instead just accept an infinite length, and provide feedback on it allowing people to alter the title to perfection until the error goes away, no mangling or deleting title contents.

Not everything that posts submissions to HN is a browser that will honour the maxlength attribute. For example, there are various mobile apps that scrape HN and allow you to submit urls.

Server side validation is entirely appropriate.

Server-side validation is always appropriate, but client-side validation is often (and certainly in this case) worth having as well.

I think limiting the number of characters is a good solution when Javascript isn't available, but warning the user that their input is too long is a more friendly solution where possible.

Imagine if Twitter limited you to exactly 160 characters when you were composing tweets, instead of indicating you were over. It would be maddening.

<input type="text" maxlength=80 /> would provide a better user experience

Worse user experience.

It chops off the end of pasted/bookmarklet titles.

Or something like: <input type="text" onInput="if(this.value.length > 80) { this.style.background = 'tomato'; } else { this.style.background = 'white'; }" />.

No it wouldn't. Users who paste the title wouldn't be able to edit out the least relevant section of text without pasting it somewhere else first, editing it, and pasting the resulting modified text in. It's far better from a UX perspective to let the user do whatever they want without stopping them but inform them that there's a problem at the first opportunity. Ideally, in this case, there should be some JS to input events on the entry box that highlights the text that's over the limit. With all the server side validation as well, obviously.

For an example, Twitter's entry box on their web app gives a character count in the bottom right but still lets you go over, but anything over 140 characters is given a background color of red. It's very clear to a user what the problem is.

Everything you say has been said already.

Reply on news.ycombinator.com