Hi Rod,
It seems to me that you’ve got two good threads going here: why hasn’t more been done with this wonderful scripting capability of Window-Eyes, and how well to collaborative projects work out? Are they the answer to turning out good quality complex software? The first is really a puzzler to me: you’ve got this great programming environment, and, you as a blind user have a need for constantly better access to the world of computers. There’s simply too much going on for GW to address everyone’s needs. At first I thought it was a simple case of people not knowing what they had here. I don’t think that’s it any longer; it’s been more than long enough for users to know about, and learn, this scripting environment. Yet relatively little sophisticated scripts have been released from other than GW. Is it a question of the environment not being up to the advertised task? That is, is no one producing anything because you really can’t? I’d say obviously not, GW is producing very sophisticated apps, and at first people like Jeff bishop (who wrote one for WinAmp), have shown it can be done. (and I don’t mean it can only be done in VBScript). I haven’t heard from anyone a serious complaint that they can’t really improve accessibility with WE scripting. One idea I’ve mentioned recently is that anything of any substance which has been released of late has been encrypted <frown>, and so not open to help teach and inspire others to write more, using those techniques and ideas. Very disappointing. I really don’t know though why we aren’t seeing more substantive apps, and hope others will offer up explanations. As for collaborative programming projects: they can work; the folks writing NVDA (a freeware screen reader) are trying this, it would be great if we could get one of them to comment on the ups and downs of being part of a collaborative effort. Many others software products are written this way. They do have a reputation though for being slow to develop, counting on as they do, the volunteer efforts of others. I do think there’s a lot of overhead in running a collaborative effort: In just managing the tools used for checking in and out modules, managing releases, testing, trouble tickets, all of that; I think it may be that only the biggest of projects (with lots of participants) can still make progress forward once you start requiring anyone who wants to make a contribution to learn to use all of those tools. But, I haven’t done it myself, so I’m only guessing. My thought with what I’m working on at the moment was that instead of waiting to ask for beta testers after my programming was done (Thanks Katherine, I saw your message), was to try some collaboration beforehand, but not quite so advanced as running a collaborative programming team. Maybe I could show some people what I’ve got so far, and tell them what capabilities I know of which would be possible to add, and get some advice on how the application might be better structured. What parts are confusing, what parts need more options; whether the app is even thought to be all that useful. Design work in other words, not bug finding. I would still do the programming and release the product, but I’d do it with the advice of some people who might end up being the final users. I’m wondering if this would improve what’s released, and allow me to skip the overhead needed in running a multi-programmer project. I have a feeling you’re right Rod; collaboration could help us do more, I’m just not sure what the best way to collaborate is. I do know I’ve needed someone at times who is skilled in the software tools used for audio production (making various little sound cue files perhaps); and I’ve needed people who are good in creating audio tutorials, and people who are unusually gifted in creating WE XML dialogs. So you’re right, the question’s is how to make it work, without having us immediately start out with differences of opinion (you know: I want to use my favorite language of choice, it’s obviously better than your language … which is how my efforts at collaboration before ended up). More food for thought, I’ve got to close now, but I’ll write up what I’m working on soon to see who’s interested. Chip From: Rod Hutton [mailto:[email protected]] Sent: Saturday, November 10, 2012 1:12 AM To: [email protected] Subject: Re: The whole GW Micro community must read this! Hello Chip, Thank you so much for writing so quickly, and so appropriate has been your response to what's been going on inside me for the past year. Briefly, when I got a new PC running Windows 7 and had to give up my batch-file loaded XP environment, which I had programmed to speak calendar events and control Winamp from the command line, my life seemed to be on the brink of despair. With the help of your tutorials and those tutorials GW Micro did, I learned to use vbScript and to get my head around object-oriented programming. What a laugh, but would you believe that the first object I studied on the Microsoft Developer's website was the Windows Scripting shell, which I put into a subroutine to call whenever I need a command-line utility to run: Sub RunShellCommand() Set oShell = CreateObject("WScript.Shell") oShell.run ClCommandLine, 0, True Set oShell = Nothing End Sub 'RunShellCommand() I did this so that I could use my little batch file utilities (and I'm still using them), as I eased myself into programming with the Window-Eyes object. It still makes me chuckle, but, whatever works, eh? Not only that, I tried to avoid learning programming so intensely that I even investigated a program called "Automate," a program which allows the creation of programming tasks without writing code. Of course, I soon learned that it had a lousy user interface, so I abandoned that idea. However, from looking at that software, I came away with the idea that, if we blind people could get a bunch of specialists together, each gifted in his or her own way, we could design solutions for all kinds of computer tasks in a fraction of the time each of us could do it individually. As for the Wikinomics book, its main tenet is that collaboration, sharing, and openness are the means by which all work will be, and is already being done, in society. No more secretive hoarding of technical insights, media content, etc. What really surprises me is how little work has been done in terms of app creation since Window-Eyes 7.0 embedded its scripting facility. There should be much more production than we presently have, and yet you know how brilliantly-powerful Window-Eyes is now because anyone who knows any programming language can write scripts to make any program speak the way we blind people need them to. So what's stopping us? I think the problem is individualism taken too far. I know you can program in your sleep, Chip (well, I exaggerate a bit!), and I have become pretty confident myself in seeing how I can use the Window-Eyes object. But, here's my problem: like you had said, I also do not have tons of time to do the grunt work of coding apps. While I can do coding, it gets to me if I do too much of it, especially when, in the back of my mind is a feeling of resentment that a lot of the grunt work could be alleviated with a collaborative effort of three or four people. And, of corse, coding is only a fraction of the work required to make decent apps. Here, off the top of my head, is my vision of a GW Micro scripting collaboration: - one person might love programming the nuts and bolts of dialogs and INI files - another has a skill in designing systems, including dialogs, but having a good sense of how to perform tasks quickly and efficiently - another might have a good sense of how beginner program users could be eased into using apps, without being overwhelmed by too many advanced options, although those options are available when they are needed; this person would have a gift for compassion on the non-technical user - still another could be an excellent documentation technical writer - and, finally, although the list goes on to infinity, maybe another person just loves criticizing apps, to see how they can make them crash, and is always making suggestions to make them better You see, all of these tasks are part of writing apps, and we need to start creating teams to accomplish each of these tasks, and then each sends a delegate to an overall app planning team. This is not a grandiose unrealistic vision. I think we're wasting resources if we don't make it happen, Chip. So, Chip, let's talk a bit more about how we want to proceed, and, if you like, we could use the app you're currently working on as a pilot project for the new collaborative endeavour I've been speaking about. I would be honoured to be on such a team with you. Collaboratively, Rod Hutton
