Hacker News Reader

Comment by yellowapple | Hacker News Reader

You could easily address those concerns without turning what should be a simple video into a clusterfsck of Javascript. For example:

    https://mytube.com/$username/my_first_video.ogg

With such a scheme, you immediately know who made it - $username - and (if this hypothetical mytube.com built a proper website) navigating to mytube.com/$username would return a list of videos (maybe with some additional routes for playlists or categories).

Sure, now the user would have to go through the additional work of editing URLs if they want to access this endpoint manually, but then this article's points come into play: if your users expect more functionality than what the World Wide Web does well - delivering content - then a native app is probably preferable for everyone involved (and, indeed, exists for sites like YouTube).

View on HN

When most people ask, "Who made this" they aren't looking for a character string that matches /[a-zA-Z_0-9]{3,12}/.

They're asking: what person or persons did this, what might I know them for, what do they look like, how popular are they, do they have a logo I might recognize? YouTube and Vimeo provide that information right next to the video, which is where people want it.

If a native app really is preferable, then I'm sure we'll see YouTube wind down their web interface once everybody stops using it. But my guess is that they'll still have an HTML version long after you and I are both in the ground.

URLs are opaque strings to the typical user.

My point was that the typical user would be better served with a native app that turns that URL into less-opaque data.

And even with the URL alone, that's still significantly less opaque than YouTube's current method of https://youtube.com/$some_random_gibberish. At least someone could see something like https://mytube.com/j_random_hacker/how_to_computer.mp4 and guess that "j_random_hacker" is a username and "how_to_computer.mp4" is a video uploaded by that user.

This isn't much different from, say, reddit, where URLs are actually part of normal discussion; a redditor will talk about a subreddit called "/r/mylittlepony" or a user named "/u/Unidan" or somesuch, directly referencing paths (to https:/reddit.com/r/mylittlepony and https://reddit.com/u/Unidan, respectively). Granted, reddit's userbase is somewhat more tech-savvy on average than, say, Facebook's or YouTube's, but it shows that URLs are not necessarily opaque to typical users, and it's certainly not hard to even manually demonstrate such things to new users.

This also isn't much different from many (most?) news sites, which provide URLs that resemble the name of the article (with some adjustment to make everything lowercase, turn spaces into underscores, strip or substitute special characters, etc.).

> a native app that turns that URL into less-opaque data.

Like a web browser?

More like any application that interfaces with a JSON-based API. Those API calls work by talking to a server over HTTP(S) and requesting something from a URL.

There's no reason why a native app can't do this - in fact, many native apps for things like YouTube and Pandora and such already do this.

But how would that serve ads to the eyeballs? You forget that most of modern webcontent is just packaging fluff for eyeballs to more easily digest the real content payload - the advertisments.

That's not my problem. If it were, I'd solve it by embedding ads in the video stream itself, which is how traditional video broadcasters have done it for more than half a century. In the audio realm, Pandora already does this with third-party clients perfectly fine.

So are most other schemes for information organization, but that does not make them inherently less useful.

Reply on news.ycombinator.com