- From: John Russell <ve3ll@rac.ca>
- Date: Fri, 4 Aug 2000 12:20:22 -0400
- To: www-amaya-dev@w3.org
AddAmaya.txt 2000 July 25 Some enhancements that are desirable for a future release of Amaya are: Accessibility A1] A menu item for selecting underlined or (user selectible) colored links is needed for average users. The stylesheet method works well and is to be preferred but this technique is beyond the skill level of the average net surfer. A2] Moving over one of the hyperlink areas should indicate that the zone is active! One can't assume that they will be of a different color than surrounding text or underlined. One possible way of enabling this kind of feedback in a user preferred manner is by having a Special -- General (or its own subitem say Accessibility) dialog box with checkboxes (to allow multiple choices) for: a] hover type display (with optional color choice) b] show selected address in status line c] change cursor to hand or different icon Of course no checked off boxes allow action to be as it is now. This allows the user flexibility in choosing the feedback method. Perhaps a checkbox could also be included for underlined hyperlinks even though it is now the custom to use the default stylesheet for this. A3] This accessibility dialog could be extended to allow background color/image to be overriden by those with color impairments. A4] The accesskey attribute needs to be enabled for pages such as w3.org that encorporate it. Internationalization I1] Offer parallel files in supported languages for all help files. I2] Allow language dialog selection to also chose help file language. Keyboard Shortcuts K1] Either a menu function or an external utility should be provided to find the keystroke action number or logical name for nonstandard keyboards. K2] The complete keyboard naming convention should be documented as well as the priorities for conflict resolution. K3] Keyboard associations are needed for the middle set of the keypad [i.e. arrows, home, page up, etc.] Appropriate settings should be set up and then documented in the help pages. Some settings may be: alt-page up/down - move to beginning/end of screen display arrow key - move one character/line in correct direction ctrl-arrow - move one word alt-arrow - move one screenful in appropriate direction home - move to beginning of line end - move to end of line alt-home - move to beginning of file alt-end - move to end of file Geometry Manager G1] Automatically save user positioning/sizing state on exit. A bonus would be a Reset Window state to the original menu item in the Special - Preferences menu. G2] Documentation of location of geometry settings file would help in cases of user having to fix poorly positioned windows. Browser Issues B1] Complete implementation of the CSS1 style functions. B2] Complete implementation of the HTML 4.0 specification. This includes floating image elements! B3] Framesets are currently not supported although they are a part of HTML4.0 specification. Since many web sites offer frames as appropriate solutions for menuing, Amaya should offer basic browser capabilities to view as many sites as possible. B4] Redisplay time should be optimized or image height default increased to prevent strobing on directory pages with images. A set of images causes a series of redisplay of pages. An example of this is http://www.neta.com/~cherry/mathml/ B5] Page scrolling should be designed to retain one/two lines of information. This allows continuity for viewer. B6] Fonts should be anti-aliased. B7] GIF transparency should be supported as sites often use it to provide margins and watermarks. Is there some way of checking Amaya .gif rendering for this. B8] Animated GIFs are not supported even though they are a common format on the Internet. Although other formats may be technically superior, democracy should rule in favor of supporting this format. B9] JavaScript should be supported due to the widespread use of it on the web. Without JavaScript, many sites cannot be browsed effectively. User Interface [GUI] U1] Tidy.exe should be callable on current file using an icon (similar to refresh). This would allow a page display problem to be quickly isolated to authoring syntax or Amaya rendering. It would also let viewers get to information on busted pages easily. U2] User menu settings should be retained and not lost on program end. An example is EDIT MODE. If toggled off, it should remain off until user requests that it be turned on. U3] Retain a history of recent URLS in a scrollable URL address box. U4] A treed bookmarks structure should be built into the toolbar or menu system. One should be able to edit all properties of this bookmark. This will add greatly to the BROWSER side of Amaya. U5] If a file is taking a long time to download or to render, there should be a flasher or gauge to reinforce the fact that activity is taking place and that nothing has 'hung-up' or crashed. Documentation D1] A menu item on the Help menu for 'Contents' or 'Index' should be provided. This selection would point at manual.html which is a good table of contents for the delivered docs. D2] A menu item on the Help menu for FAQ on w3.org should be provided. This selection would allow dynamic addition of instructions missed in delivered documentation. D3] More work is needed in the delivered doc files to ease new users into Amaya. Documentation is well detailed for the advanced users but is awkward for people who are new to Amaya. D4] Documentation should include a page of features NOT included within Amaya that other browsers normally have. A brief mention of the implementation decision will help users understand why it isn't there. This could be either on the web site (on the FAQ) or as part of the delivered docs. John Russell, VE3LL@RAC.CA http://www.cgocable.net/~jrussel Mystery readers may want to click on DOROTHYL
Received on Friday, 4 August 2000 12:19:25 UTC