Hacker News new | ask | show | jobs
by sjs382 5716 days ago
I built http://isshort.com because I wanted to promote healthy link shortening, and created an API so that Twitter clients can use it. I promoted it on reddit, HN, techstartu.ps, Quora (in response to a question) and by emailing the people who were an inspiration for it (simon wilson, the people responsible for rev=canonical and rel=shortlink).

I've been completely unable to gain traction for isshort.com, with 43 visits to the site in about 5 days.

6 comments

Let me give you some feedback for isshort.com.

1. The landing page does not tell what the service is for and who is it for.

On the first look, it looks like just another URL shortener - but why would I use it over something like 3.ly or j.mp?

2. I tried to read the explanation but bored out. I don't care what "healthy link shortening" is or what rev="canonical" does. The blog post is longwinded and filled with jargon and terms I don't understand. "Publisher"? Am I a "publisher"? Do I want to be? What is the target audience? Am I in the target audience? It's difficult to find out.

3. I put in "google.com" and out comes INVALID_URI.

4. Not having a "Submit" button feels somehow awkward. I'm not sure what I should do in order to shorten the URL. I eventually discovered that pressing Enter and clicking on the "isn't short" text works, but I'd feel better with a "Submit" button.

Amen to all of that. I didn't know until I tried it with an unsupported host that it would turn around and provide a j.mp short URL, which is great, but non-obvious. Until then, I'm wondering why I'd want to use a link shortener with a seven-letter TLD.

It's a serious mistake to disallow shortening TLDs like "google.com", because that's what people are likely to type in to test the service. It's deadly to ever let a user see a hostile, wholly uninformative error message like "INVALID_URI".

Owing to unnecessary ajax and a submit button which doesn't reflect presses, if I fail with google.com and then try yahoo.com, there's no indication that the site has received or acted on my second attempt.

Labeling your only button with an image, in an oddball font, using text that's both passive voice and a negative statement, is not OK, as you implicitly acknowledge in the introductory blog post, when you have to tell your potential users which piece of screen real-estate to click.

I knew what rev=canonical and friends were, and even I didn't have any idea what the phrase "healthy link shortening" meant to you. I thought it might have been a point about not relying on the Libyan government. The introductory blog post isn't doing its job. The list of sites with their own shorteners should be on the front page, and should be longer — that's how you connect the site's value with potential users.

The service itself is useful, though I'd most like to see it incorporated into Twitter clients like Hibari, which use bit.ly for everything. Evangelizing an API is harder. Good luck.

Yeah, the API is the product. The website is a demo.

I will work on explaining this a bit better.

Thanks for #1 and #2. I'll reconsider my approach. I didn't know that was confusing.

3. Thanks again. I wasn't aware of that. It's bit.;y's error message, not mine.

4. I will implement a submit button soon.

People complain about link shortening on sites like HN, then turn around and use bit.ly because it's easy, just works, and gives cool real-time analytics. You're solving a problem people _say_ they have, not that they _actually_ have.

Healthy link shortening is a 'nice to have', not something most folks will go out of their way to us.

But it's not something they need to go out of their way to use, is it? It's just something you set once and forget about. My API doesn't even require any authentication. :)
You're arguing technical merits, not user benefits. It's the 'set once' part that's the trick. It's really, really fucking hard to get someone to set something new one time, even if it is a good bit better.

Personally, I wouldn't start using a new tool for the benefit of the web in general when there's an immediate benefit to me for using a competing product. There's got to be a user benefit besides improving the web.

Whats your immediate benefit, as a Twitter client dev, to register for bitly and get an API key rather than just posting to isshort.com/api.php?

You're confused about who I consider my user. My target audience is a developer, not an end user. The web page is only there as a demo; the product is the API.

Developers who use bit.ly don't see this as a problem - they like bit.ly because it can give them some intelligence into who uses their products and what they are linking to.

Publishers would like people to use their shortener, but that doesn't give developers anything.

Most consumers don't care. Some do, and prefer bit.ly because they trust it (and they like the intelligence it gives them)

Are you seriously wondering why people aren't flocking to your new link shortening service? Could you possibly have picked a more crowded niche with less demand from real users and less potential for profit?

If you're going to build something, throw it live, and hope people find it, you're going to need to make sure it's something people will actually be looking for. There are lots of things like that. There are actually only a few that aren't, and unfortunately you've picked the biggest one.

To give you feedback about isshort.com, I took me a long read in the blog to even start to understand what it does.

For what I got, you use the shortener of each website (if available) to generate a short URL. Like use youtu.be for YouTube URLs and default to j.mp otherwise.

You claim on the front page to be a different kind of URL shortener and with my first try it seemed to be just as any other URL shortener. You give a long link, it makes a short link.

You should maybe put a concise text on the homepage about what it does and why it's better. Not in a super long blog post that starts by saying when people use URL shorteners

Thanks for the recommendation. I guess the intro to the blog post was a bit fluffy. I'll clean it up a bit later today, I think.
I've tried to use it with http://www.squaremeal.co.uk/restaurants/london/view/80677/Ha..., but it didn't pick up rel=shortlink.

UI is a bit weird — there is no submit button, no progress for the magic ajaxy thing.

Page that explains what it's about starts with mix of obviousness and downsides.

1. Ah! With that link, it's because the attribute isn't in quotes. I'll fix that right away!

2. There is a submit button. The "isn't Short" image is a button. I'll fix that soon. Also, I'll add a progress bar. Is that something that's really detracting from people using the site, though?

3. How would you restructure the blog post about it?

Button should look like a button (have affordance). "isn't short" is not a good label — it's not a command (you isn't short URLs?).

If button gives click feedback and you can shorten in 1-2 seconds, then you might not need a progress bar.

Explain on the page, in something that can be read in 4 seconds, what is that any why should anybody use it (problems you solve that others don't).

Assume nobody reads the blog post.

Either the people that would be interested in it haven't heard about it yet (and you need to promote more), or it's just not interesting to almost anyone (and you should just give up).
I don't agree with your suggestion to give up. What he should really do is "pivot".