Hello hyrichter,
Just a quick note to say thanks for making an alternative IDE to the default DBP one!
I am a blind developer that works full-time as an asp.net certified web developer. I program audio games for the blind on the side to get a break from the grind of business development.
I've not had the time to read all posts but if you are still looking for a person to test a large project let me know.
Also, I'd be more than willing to work with you on adding some enhanced accessibility support to the product. More less just adding keyboard keystrokes to all functions in the application and helping you standardize on Microsoft's standards for keystrokes.
Here are a few accessibility considerations to start with...
in the options for the product, in the code highlighting section, consider adding a check box "do not use code highlighting" so when it is checked code and syntax highlighting will not be used. That is helpful for blind developers since it can cause certain brand screen readers to bug out.
Note: you may already have that in place I did not "see" it though in the options.
Good job with the feature to turn off line numbers - I personally hate them *grin*.
The debugger is not working for me since I am currently trialing dbp. I plan to pick up a copy of dbp if it meets my conditions for developing commercially sold audio based games. So far though, it is looking promising.
With regards to code surge, it would be nice though, if not supported, to allow people to use keyboard keystrokes to step through code while in debug mode as in vs 2003/2005 IDE. I.E set a break point in the source, run in debug mode, break at the line and then press f10 to step one line at a time through the code. I think the dbp IDE only lets you use the mouse to click to execute the current line/step over it. Not sure if dbp IDE has an accessible window to view variable values in the such, as again I am just trialing it, but if it does not this would be a helpful addition to code surge as well.
One thing I like to do when I develop windows applications is add an "Actions" alt+a option to the menu bar. Under it I add all toolbar button commands with associated keyboard keystrokes for accessibility compliance if the keystrokes are not found under other pull down menus. I.E I would not put ctrl+o under actions since by standard it is used for open file under the file pull down menu.
Note: Microsoft accessibility standards state that for any toolbar button, there has to be a menu option for it to with a keyboard keystroke. This is since some brand screen readers cannot interact with a toolbar strip so having the keystroke to press is crucial. I cannot tell you how many applications I have performed qa on and the developer has a toolbar button for a main function of the program, for example run, and yet has *no way* to execute that command via the keyboard so the application is useless to a blind computer user.
I also do not use windows standard keystrokes for other functions in a windows application. For example:
ctrl+c - copy - I would not use for open code
ctrl+x - for cut text - I would not use for exit application
ctrl+v - paste text - I would not use for view variable value
Note: I noticed that under the edit pull down in code surge the cut/copy/paste functions did not have these keystrokes in place.
A quick way, while not fullproof, to pick up on what Microsoft standards are for keyboard access/keystrokes is to open up Microsoft Word, word pad, etc. and look at each pull down menu at the top. Note the underlined letters that they use for menu options as in file, edit, view, etc. alt+f - alt+e - alt+v etc.
code surge seems to have those in place. good job.
Also in the product documentation it is very helpful to have a "keyboard shortcuts" section that simply lists all the keyboard keystrokes for easy reference. In the DBP default IDE there isn't even a keyboard shortcut listing in the help docs!!! This has been another level of frustration for me. Lets just say that the DBP IDE does not follow windows development standards, well it does about half, and it certainly fails with regards to microsofts accessibility standards.
Note: while I may be primarily offering keyboard shortcut suggestions, it is interesting to note that many developers, while programming, prefer to use the keyboard for programming source code since it is faster. I.E ctrl+o for open a file is much quicker than:
1. take hand off of keyboard
2. grab mouse
3. wheel it to point to file
4. click file
5. point down to open...
6. click on open
another example...
it is much quicker in a multiple document interface to press ctrl+tab to cycle through open files than:
1. take hand off of keyboard
2. grab mouse
3. point to tab in mdi tab strip
4. click the file you want to switch to
5. put hand back on keyboard and begin to program
With using the keyboard for program functions your hands never leave the keyboard which leads to more productivity. I could go on listing a ton more examples but will stop, I think you get the point *grin*.
Actually at my day job all developers in my shop, around 10 of them - I am the only blind developer on staff, all prefer to use the keyboard when programming since it is much quicker than the mouse.
The only downside is that you have to memorize the keystrokes. However, this is why it is crucial to follow Microsoft keyboard shortcut standards since 80% of the knowledge will apply to any application as long as you follow the standards. I.E ctrl+o should always be for open a document/file, ctrl+n should always be for new file, ctrl+x for cut, and so on. This way as you interact with various applications the knowledge you have and expect to be in place for keystrokes is there which in turn lessons the learning curve.
Any how, hope you have found this post interesting and again, I am here to help if you need it.
Regards,
Frekster
Who really needs to see to program? Isn't it all just text anyhow?
