Yesterday I presented my findings about the Wii browser. Today we shall do the same with Lynx.
Lynx is a text-mode browser which renders on terminals. While it will work on a VT-100, it will greatly benefit from a color terminal. I have found Lynx to be useful when browsing the web from low-bandwidth and/or high-latency settings. For instance, from my student room in a few occasions getting at the wider web would fail, but I could connect to school machines just fine, so I logged by ssh to my school account. Unfortunately, while I could tunnel an X window connection a graphical browser used in such a way was pretty much unusable, but Lynx worked very well.
At this point I need to note that I am not doing web design by any stretch, rather I try to make sure my writing can be read without hassle on such a target.
So first, Lynx has a number of limitations coming from the display device. For one, there is only one font, determined by the terminal or terminal emulator, and it’s not possible for Lynx to change it. Furthermore, font rendering is pretty primitive, don’t expect proportional text, varying font sizes or (God forbid) kerning or ligatures. There is no italics either, though Lynx will try and make sure italics and bold are highlighted in some way through the use of color, the same goes for <code>. The same way, in order to emphasize <h#>, Lynx renders them flush to the left, while paragraphs are indented.
Lynx is also Unicode-aware and will understand and convert between the different encodings and render to UTF-8 if the terminal supports it (which is common for terminal emulators nowadays). So don’t get the impression that text-mode and terminal mean straight quotes and simple hyphens. All in all, despite the limitations Lynx will render your text and at least the meaning of your text formatting as best as it can.
Besides your text itself, however, it is important to remember that Lynx is a text-mode browser. Besides no images (so don’t forget the alt text!), this means it will not attempt to interpret your site layout and try and render it with box drawing characters or anything of the sort; instead, your text will be rendered in the order it appears in the HTML source, so if you have a side column (like navigation) whose content is after the main writing in the HTML source, it will appear after your writing in Lynx (which may be what you want). This also means that you should avoid having too much navigation boilerplate at the top: what appears as an unobtrusive 30 pixel high row of buttons/menus in a graphical browser will show as a laundry list of links, with menus unrolled, that the user has to scroll through at the start of every single page.
The user interacts entirely with the keyboard; it’s pretty spartan, but efficient: base commands are space/b to scroll down/up a screenful of text from a page, up/down arrows to navigate links, right arrow to follow a link, left arrow for back (a development tip: you do ctrl-R to reload and refresh the page). Some site navigation options, especially if they are after the content, may not be as discoverable for the user as on a graphical browser, on the other hand users will gladly search, so make sure you have a search box at the top, clearly marked (with text!), they will take it from there.
In the end, don’t neglect Lynx, you might not think of it as useful, until the day you need to check the content a site serves when seen from a machine on which you happen to have a ssh account…