[Links] Suggestions for user interace improvements
"Philip Ganchev" <[email protected]> Mon, 9 Oct 2006 05:19:06 -0400
| Newsgroups | gmane.comp.web.links.list |
|---|---|
| Message-ID | <[email protected]> |
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. _______________________________________________ links-list mailing list [email protected] http://linuxfromscratch.org/mailman/listinfo/links-list