Hacker News Reader

Comment by falcolas | Hacker News Reader

A bit meta, but...

Part of me appreciates that there is no magic javascript which mucks with the browser and makes the slideshow a real pain in the butt to navigate. However, this is going too far in the opposite direction. Each slide as its own page? Navigation is slow, all-but requires the mouse, and creates a N-length list of sites to go "back" through to return here.

Can we just come to a compromise: one page with each slide below the last? Allow us to take advantage of parallel fetching of assets, use native scrolling to progress, and you can even create anchors to link to a particular slide!

Even better, you could easily write some basic javascript and to turn such a page into the former version of a slideshow if you're so inclined.

View on HN

I always found the OpenBSD slides above anything else I've seen online. I just hover my mouse over the link to the next slide and because the links stay a the same point on all pages I can just click when I want to progress.

With the exception of the slides from Henning Brauer, who pick horrible red images for the background, most of the OpenBSD slide decks are very easy to read. Do anyone really care that they're using Comic Sans?

I didn't event realize it was a slideshow until I read your comment.

Feel free to submit patches to magicpoont...

I was actually reply to gp along the lines of "blame your user agent for not providing navigation help with rel="next"[1] links" -- but having a look at the html-source, apparently magicpoint doesn't generate rel="next" links anyway...

And the link to magicpoint[2] is broken -- so where would one submit patches? The first one should probably be a new "generated by"-link that actually works...

[1] http://microformats.org/wiki/rel-next

[2] http://www.mew.org/mgp/

Magicpoint is located here:

http://member.wide.ad.jp/wg/mgp/

I've no idea how one would submit a patch though.

Fix all the bugs, upload to github, announce "magicpoint-ng is here!" Very simple. :)

Well, as far as I can tell, the URL is fixed in the latest snapshot: ftp://sh.wide.ad.jp/WIDE/free-ware/mgp-snap/mgp-snap-20150831.tar.gz -- but after a bit of fiddling I couldn't get the configure-script to build with libungif installed under my home-directory...

Looks like the html "template" is embedded in mgp.c, in the genhtml-function:

  496 static void
  497 genhtml(start_page)
  498     int start_page;
  499 {

There's apparently only one reference to "next page" (page +1):

  596         if (page < maxpage) {
  597             fprintf(html,
  598             "<A HREF=mgp%05d.html>[next&gt;]</A> "
  599             "<A HREF=mgp%05d.html>[last&gt;&gt;]</A>\n",
  600                 page + 1, maxpage);

I guess:

  596         if (page < maxpage) {
  597             fprintf(html,
  598             "<A HREF=mgp%05d.html REL='NEXT'>[next&gt;]</A> "
  599             "<A HREF=mgp%05d.html>[last&gt;&gt;]</A>\n",
  600                 page + 1, maxpage);

might do the trick?

Then one could either add a js-shim to navigate based on rel=next, or use a client with support for that. Or, use a more modern package for generating slides. That'd be my first choice. Something like pandoc with S5:

http://pandoc.org/demo/example9/producing-slide-shows-with-p...

http://meyerweb.com/eric/tools/s5/s5-intro.html

Or (I don't use Emacs, so no idea if this really works) org-s5:

https://github.com/sigma/org-s5

Then again, I suppose there are no perfect tools...

A js-shim for navigating with [←] and [→] would be definitely nice, after one added the rel=next.

And it would degrade nicely, too.

I remember when `graceful degradation` was still a thing...

This was developed to work in all browsers. Even 1995 ones. Why change it? It still works.

No, it wasn't developed to work in all browsers - jpgs don't work well in text-mode browsers like w3m or lynx. Likewise, jpgs of text are worthless to things like screenreaders, and there's no useful info in the alt text. jpgs of text also don't work with people who have tools to style pages so they can read them better. Ironically if they had've just used simple text, it would have worked in all browsers.

In addition to this, the OP suggests ways in which it doesn't work well. Just because something 'works', doesn't mean it can't be significantly improved.

Funny enough, JPGs can work in links.

Sure, but not on a default install. This is what I see on a basic install of lynx: http://i.imgur.com/UlxBCk4.png

Links, elinks, and lynx are different browsers.

Ah, my mistake. I just assumed that you could add a plugin for graphics. Thanks.

Because it makes the presentation hard and slow to read.

(To keep the meta posts in one place)

Even the OpenBSD project is talking about "disruptive innovation"! The tech industry has really collectively jumped the shark.

Well, if you open that single page containing all the slides, and there are many slides, you would be putting a lot of load on your server. So then you would still need some magic javascript to make it load in a delayed way.

Most browsers (I know Firefox, Chrome, and IE) automatically limit the number of concurrent requests they'll do on a single server.

Adding JS to only prefetch, say, 10 slides forward, might be a good progressive enhancement, but not a requirement. And, along the lines of what someone else said, if your server is excessively burdened by a malicious client, or even one that doesn't execute your JS, that's a server problem.

Those arguments are flawed for the following reason. Suppose your website has a single slide per page. Let's say the website allows N simultaneous users before it breaks down (becomes too slow). Of course, even a superfast server will break down at some point.

Now, suppose browsers perform X concurrent requests (because of built-in behavior of the browser). Suddenly, you can not serve N users anymore, but only approximately N/X users.

If your server can't handle serving up 1-200 images at same time, your server sort of doesn't deserve to be on the internet.

Any server today should be able to saturate it's network connection serving static content.

If there are 1000 simultaneous requests (from many users), 1-200 images become 1,000-200,000 images. I hope you see now why your argument is flawed.

Nope. My argument "Any server today should be able to saturate it's network connection serving static content." still stands. Which I wrote as clarification to stop someone from thinking / posting what you did.

It doesn't matter how many requests for same images. Any server should be to fill network link serving static content. Even slow Apache could saturate 100Mbps 15! years ago. https://www.devside.net/articles/apache-performance-tuning

Those 200 images all fit into memory. All the server is doing is answering requests and copying those to the network interface. No disk IO, no computation, maybe not even the copy if server/nic can do zero-copy.

I understand what you say. But consider the server as being the machine including the network interface. Then, still, the pipes are going to be congested sooner with multiple images instead of a single image per page.

also, comic sans ;)

Reply on news.ycombinator.com