[Links] Suggestions for user interace improvements

Philip Ganchev phil.ganchev at gmail.com
Mon Oct 9 03:19:06 MDT 2006


Hi,

Here are some ideas for improving the user interface of the wonderful
Links web browser.  I realize that the developers probably have little
time to spend on Links, so these ideas may never be implemented.  I am
putting them up for discussion, and perhaps someone will eventually
implement some of them.  (I cannot yet write C, unfortunately.)

First, I think forward history would be very useful.  Users often
navigate back in history and then again to the page they were at.  An
unofficial patch for this by Peter Wang is at
http://links.twibright.com/download/unofficial_patches/.  The
associated txt file says it si too dangerous to put into the main
release.  Why?

Underline links. They would be easier to recognize, especially if they
are colored in an unusal color.  Also, it is clear which words are
separate links and which are together one link.

Use the status bar instead of dialog boxes for URLs and text search.
Dialog boxes are too obtrusive; they may hide the search results or
the text needed to compose the search query or the URL.   The status
bar is inactive anyway if a dialog box is present.

In graphics mode, support copying text from dialog boxes like the URL
box to the X clipboard, and pasting to text boxes on the page. This is
makes transfering information like URLs and search terms much easier.

Some kind of smart bookmarks, that would allow the user to use web
search and lookup (like Wikipedia, dictionary) without first
navigating to a website.  An easy way is to provide a home page
shortcut and so that the user can create a local home page containing
text boxes and buttons for the appropriate web search services.  See
for example http://www.cs.pitt.edu/~philip/.portal.html . Using a
local page reduces the latency for searching.

How can I stop the loading of a page?

It would be great to remove modes.  A mode is a difference in way a
program responds to a gesture in one state versus another, while the
user's locus of attention is not the state.  In Links, scrolling using
"[", "]", "Insert" and "Delete" is modal because it does not work if
the focus is inside a text box or a text area (and the result is
completely different).  The user has to check every time, and exit the
text area if needed.  This is slow and distracting.  Other modes are
pressing "z" or "Backspace" to go back in history, "h" ot display
history, "=" for info, etc, although it is possible to use the menus
(Alt+f, etc).  All these can be removed if the key combinations for
the actions include the Control key.  Single keys can still be
supported for users who (think they) like to use single keys.

If no page is loaded when Links starts, show the "Go to URL" box
automatically.  This is the only way to navigate, so it saves hitting
G.

Do not hide the meny bar.  This saves not only saves one mouse click
to activate the menu bar, but also the navigation to the right menu is
easier.  Also, a new user may not know there is a menu, but if it is
visible, most users will know how to use it.  Use grey color to
distinguish the menu bar from the page.  If the menu and the URL
cannot fit together at the top line, draw the URL over the last part
of the menu.  If the user clicks on the top line, draw the menu over
the URL.

Since the code for zooming is already implemented, why not make a
keyboard shortcut to allow zooming on the fly, wihtout going through
menus?

Before compilation, the configure program can check which programs are
available (xpdf, etc) for viewing various file formats, and create a
Links configuration file.

It would be preferable to have sans-serif fonts instead of the serif.
They are easier to read on-screen, and Links is mostly used on-screen.

Incremental search like in Elinks and Mozilla would be very useful.



More information about the links-list mailing list