Hi Samuel, Thanks for your reply. I'll snip pretty much and only comment some conclusions and other points you raise.
Samuel Thibault wrote: > Ah, I thought would were criticizing the bare ls output. Well, yes, Now that you got me going about this, I am, <grin>. I mean it lists multiple files on a line and most people cursor stuff in line chunks using console screen readres. So what I'll use in stead nearly always is ls -1. And I'd like to make that the default including piping it to the more or less commands. Well, does the alias syntax you showed me also work for zsh? Guess I should install it and read the manual. > Just use the --time-style=locale option. Again, the standard unix way is > to use the format above. Is that the C-locale? > The problem is _not_ to have programmers start thinking about this, > but to provide them information so that they can put themselves in your > place. I agree most of the time. SOmtimes it seems accessibility and usability conflict with each other, and in those cases usability is likely to win. For example, separating by commas would be easier to parse in once head with speech or in most scripting languages, but most people will find spaces look nicer. > Please don't consider that programmers are necessarily lazy. They are sometimes. One such thing are error messages. I sometimes write scripts in which error handling is the first thought that comes to mind stuff like: open my $file, '>', $name or die "cannot open $name because $!.\n"; and I'm sure I'm not the only one. The thing is: It is true that the file canot be opened but from the user's point of view it might very well be a save as operation. IN which case you should talk about saving as or writing a file as opposed to opening it. GUI people will think open refers to the open dialog. > So just explain them how things should rather be done, That's a good basic strategy I've used in Windows. The advantage in there is that tab order and focus handling are expected to work. If they don't, it is not exclusively an accessibility issue and fixing it is easy to justify. The same thing with Gnome. > think twice before typing enter Hmmm, I still don't like this. I mean, people are bound to make mistakes and I often do something and think afterwords. That's why, despite being a GUI power-user, I find the Bin extremely useful. In the GUI, it doesn't confirm deletion but if I notice that somethihng went wrong, ctrl+z brings it back. I suppose this will also work with Gnome, seeing how thoroughly they've cloned WIndows. > (that's why there is usually no "undelete" command in Unix, btw). And no decent script to implement a recycle bin, right? To be real affective I suppose one would have to hook into the underlying sys calls to have this work in apps in addition to just shells. >> Which one would be good as far as confirmations go? > zsh is fine. You mentioned later on that staying in the shell is considered almost programming and I said I don't like to do that in casual file management but do like Perl, actually. So if CSH has C-like syntax and ZSH includes Perlish regular expressions, is there a Perl shell? I think I read about some such project but they aren't actively being developed. > Unix in general has the "read documentation, thenwork" philosophy, you > can't compete that. Yeah, I've noticed. And often it means read the whole documentation, experiment, read it again and then succesfully use the command. This is totally unlike Unix but I've been toying around with the idea of a shell that was as polite as a Mac and had friendly pseudo object-oriented commands and named parameters ala Python. Something that's aimed at people who can just sit down at a terminal, type in help and be using the thing in minutes. Not as powerful as Unix would be, but you could certainly make such a shell much more powerful than the puny command.com. I suppose fish is currently about the friendliest shell there is. Unix users tend to be power-users and those who prefer the GUI try to avoid the command-line but will ultimately fail. This is one of the big disappointments to me. You need text config files and the shell as soon as something does not have a front-end or is not thought to be important enough to be configured by the average user. A major annoyance is that this includes Gnome themes, which are important for low-vision folks for accessibility's sake. > Manual pages are reference documentation ( Arrgh, that's quite bad really. Fortunately GUI apps have a sounder philosophy in this. No-one expects you to absolutely master an app based on a pure menu reference, for example. I know the comparison is a bit unfair but needless to say, I really don't liek this philosophy. Fortunately, the Unix man pages aren't exactly reference like, either. They are often tens of screenfuls and go into quite a lot of detail only they aren't quite thorough enough for new users, > introduction documentation (info pages, books and teachers are there Howabout Wikis? It would be great if ordinary users could instruct each other in using commands. You could then add analogies to DOS, Mac, common programming languages including Qbasic etc... > unfortunately) few people know. Type info coreutils for instance, for Thanks, will try that. HOW widely are these available? >> This sentence says three or four things in a long, >> hard-to-understand style with two sets of parentheses in it. > Well, you're welcome to rephrase it and submit it <smile> > <added> because as it is currently, this sentence is fine to me... > yes, documentation needs to be done by not-so-technical people. Quite right. I could actually find loads and loads of other similar examples. This might not match the Unix philosophy but when wearing my user hat, I don't care how something works as long as it works. Dir is documented like this so it says: /S Displays files in specified directory and all subdirectories. That's all you need to know. Unix man pages go further and state that: -R, --recursive list subdirectories recursively Which makes sense for programmers, computer science folk and mathematicians but leaves the rest wondering what they might have missed. I find the DOS version clearer. I mean how many end users need to know whether the algorithm is recursive or not? You hardly ever run out of stack space anyway. None of the GUI tools I've seen use the term recursive, and I consider this a good thing. > Mmm, I can't remember exactly which one this was, maybe mc (midnight > commander) and other such tools may fit your needs? I tried MC a couple of days back and my WIndows screen reader didn't track the focus in the terminal emulator. It is probably quite a complex app for console screen readers. Are anyone else having better luck say with Yasr or Speakup? The Norton tree is simply a scrolling ASCII tree of directories in which you can navigate with arrows and go to a dir with enter. > ":)" is indeed probably not quite well read by speech synthesis, Colon right paren. Yup that's why I use pseudo HTMl tags myself. But this would be bad as a global abbreviation. Some programming construct is probably using it. -- With kind regards Veli-Pekka Tätilä ([EMAIL PROTECTED]) Accessibility, game music, synthesizers and programming: http://www.student.oulu.fi/~vtatila/ -- Ubuntu-accessibility mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-accessibility
