A big part of manuals is being able to read or scroll fluidly into the next or previous section - very often one doesn't know whether what they are looking for is mentioned in 1.3.1 or 1.3.2 - having to manually click each section is completely atrocious for usability. Not to mention you just broke search.
If you want a responsive design that's actually useful as opposed to counterproductive, leave the sidebar for navigation (down-scale it to 50% it's huge and distracting) and restore the document to a contiguous form. There is a reason manuals have been written the way they are for dozens of years, hip and flashy design elements might sell products - but they do not help with productivity.
A big part of manuals is being able to read or scroll fluidly into the next or previous section - very often one doesn't know whether what they are looking for is mentioned in 1.3.1 or 1.3.2 - having to manually click each section is completely atrocious for usability. Not to mention you just broke search.
This, it is often split in sections smaller than the screen so you have to uncollapse way to many items. Make the navigation jump to the right section in the document, maybe allow to collapse sections, but have it all visible by default.
I am actually on mobile, and the biggest problem on mobile is spotty coverage. I click stuff and there is a slight animation but no more data shows.
I have no idea if that was because a TCP connection broke, or if this is just a design concept and the actual data is missing. I have to reload the whole page, then click down to the sub-heading I just opened and try again to know.
I haven't looked, but I get the impression you don't have any error handlers (or maybe there are crazy high timeouts?). You should always, especially if your users are on mobile networks, to put up some sort of spinner when loading data and make a serious effort of handling the errors that inevitably happens.
I applaud your effort to apply some styling to the manual, but this is, frankly, ridiculous.
To whit:
# Debian Jessie
$ du -hs /usr/share/doc/glibc-doc-reference/html/
9.0M /usr/share/doc/glibc-doc-reference/html/
$ cat /usr/share/doc/glibc-doc-reference/html/* > all.html
$ wget https://www.gnu.org/software/libc/manual/html_mono/libc.html
$ gzip -9 -k *.html
$ du -hs *
7.5M all.html # Local html
1.1M all.html.gz # -"- gzip'ed
4.9M libc.html # single-file version, from wget above
900K libc.html.gz # -"- gzip'ed
So, under a mb of data, for the whole thing -- and that's not even working with the various sections. It might have made sense on dial-up, but not really for mobile clients. The fact that you've completely broken the whole thing (eg: no mirroring with wget) doesn't make up for the savings. Also, if you'd kept the/a single html-file -- that file would've been cached, so doing some js-magic with hide/show should be instant, after the thing is downloaded. That's the old Dreamweaver way of pre-loading content (set sections/div/whatever as display:none, and toggle on mouseover link/clicks etc).
So this is not degrading css, this is just broken html for no good reason. If you want to load "partials", keep the traditional structure, and do your magic "upgrading" in js -- load the content asynchronously into a div or what-not -- and leave the links working for browsers without javascript/wget/etc.
All that said, the work you've done with the CSS is very nice. I'd probably add a media-query to collapse the sidebar -- it takes up quite a lot of space on mobile (especially in portrait mode). I'm also no fan of typekit -- if possible I'd prefer to use locally hosted (freely licensed, of course!) fonts.
And just as a reminder, on the off-chance that there might be some readers that are unaware: CSS Zen garden is still a good example of how html and css can go together in creative and gracefully degrading manner: http://www.mezzoblue.com/zengarden/
A final note on links/urls. With eg. vimperator, "gu" (go up) works for going from example.com/some/where to example.com/some/ -- so while most browsers have gotten rid of "forward" and "up" navigation arrows, they still do work.
Ahhh, thats a good point. I will fix that! I tried using iframes at first. But they are a pain to deal with. I think I can solve the back button problem without them though. Thanks for pointing that out!
I use w3m every day for a couple of reasons. May be the minority but the only reason w3m would stop working well with most sites is that we have forsaken our semantic heritage that the web was built on.
I have a big problem with this. The header says "The GNU C Library" and then in big letters "By: Elmer Landaverde".
You did not write either glibc or the manual. The original authors did not credit themselves, yet you've appropriated credit for what is essentially restyling the HTML output of texinfo into a less usable, unscrollable, unsearchable form.
If you insist on the huge attribution, change it to something accurate like "Style template by:"
> A reader emailed to complain about how this and other HN discussions often become derailed by off-topic carping about blog design. I agree completely. Could there be a more classic form of bikeshedding? It would seem parodic if it weren't sadly real. This has become more of a thing on HN lately. It needs to become less of a thing.
> I don't mean to pick on you personally, or just on this one comment. (Your second sentence alone, by the way, would have been a helpful contribution.) The problem is the tedious stampedes such comments spawn.
This submission is a bit different because the design of the page is the thing being submitted, but I'm aware that I too easily make comments about the design of the page rather than the content of the page.
Some design choices are weird and prevent people from being able read the content and I wish there was a way to provide that feedback without derailing a thread.
Arguably, a threaded forum by design encourages tangential discussions which deviate from the topic the deeper you go. The problem in HN's case is all the threads are open and entirely visible - which is one of the cases where its minimalist layout works against readability.
I think the best solution would be thread folding (which I know is being worked on anyway) where the default is that all threads are collapsed. Then, off topic discussion wouldn't take up any more than a single post's worth of space by default. Having it be a conscious choice to move deeper into a thread also ensures that no one has to scroll past much content they don't care about.
I suppose open threads by default would be more friendly, or maybe defaulting to open for mobile layouts.
But it taking more time would kind of be the point - opting in to participate rather than opting out by scrolling past content means fewer sarcastic comments about how a thread is off topic and irrelevant.
"Bikeshedding" has become yet another empty dismissal. The colour of a bikeshed is irrelevant when designing a nuclear reactor. But the "bikeshed" of a webpage has to do with usability, which is a critical component of any webpage.
Yes, when someone submits a webpage the design of that page is up for discussion.
Whe someone writes an interesting technical post about Cache Line Aliasing it's a shame when the most visible commet is a complaint about the blog platform.
I want more articles like that on HN so I'm going to stop leaving empty comments about page design on HN unless, like this example, the design is an intrinsic part of the submission.
And even here I could have worded my post much better.
Having said all that: a lot of the stuff submitted here is not accessible and that's a shame. It feels like we've gone backwards. Where you used to have a web page that had keyboard navigable elements that would announce themselves to the assistive technology it feels like we now have apps that abandoned usability and started making it up as they go along. What happens when you press and hold and image? What happens when you put your phone into landscape? Who knows, everyone does things differently.
You make some good points and you are correct that my redesign of the manual is far from ideal in terms of accessibility. I will definitely take these things into consideration and improve upon them. This is not an area I'm familiar with, which is the perfect excuse to go a learn about it!
In regards to the 'experimentation' done by websites. I would say that this 'experimentation' is something that should happen. How else are we supposed to discover new and better ways of doing things than by trying something different. Not all new things are better, and most of them fail. This trial and error, however eventually leads to better design and better 'standard' ways of doing things.
It is unfortunate that today accessibility has fallen down the priority list. Likely, a side effect of all the new ways we can interact with our electronics. So above all let me say thank you! We need people like you who remind developers to keep accessibility a top priority.
Yeah I agree with your comments. Initially I only tested as far down as tablets, because I figured that the target audience are programmers on their laptops or desktops. I will be fixing this issue on the next iteration.
This is a really great resource - so great, I'd love to have an offline copy for reference. However it doesn't look like its set up for easy mirroring with wget .. does anyone else have an idea how it could be mirrored locally for offline use, or shall I just contact the author?
Agreed that the expandable sections feel a little unusual for this type of documentation. They're great for drilling down to particular information, but not so much for skimming or reading straight through.
I might even suggest putting the sub-section navigation in the sidebar a la readthedocs.
An Expand All/Collapse All button would also be nice (but not instead of expanding by default-- the whole reason I'd be reading those documents is to read the stuff in the collapsed sections).
Yes I think so, the pane on the left already allows the user to control which section they are reading. I would assume that once a reader is in a section they would likely want to read/scan all of it. Excellent work by the way!
You are correct, this is just a restyling of the manual. Just curious, what did you think 'redesign' meant? I have mostly a front end background and I thought I was using the word correctly. But I might have been wrong.
I haven't inspected how you did it but I guess it shouldn't be hard to apply it to other GNU manuals also, as all are very similar in the sense that they all are produced using the same tools.
Another idea: local search function similar to Sphinx's would be really nice.
A big part of manuals is being able to read or scroll fluidly into the next or previous section - very often one doesn't know whether what they are looking for is mentioned in 1.3.1 or 1.3.2 - having to manually click each section is completely atrocious for usability. Not to mention you just broke search.
If you want a responsive design that's actually useful as opposed to counterproductive, leave the sidebar for navigation (down-scale it to 50% it's huge and distracting) and restore the document to a contiguous form. There is a reason manuals have been written the way they are for dozens of years, hip and flashy design elements might sell products - but they do not help with productivity.