Hi everyone,
I want to share what I think were positive results from the work we called F123Light, some lessons learned, and what I consider priorities for next steps, at least next steps I want to pursue.
Two important things for me were that this project was able to provide paid work opportunities to a bunch of talented blind persons in countries as varied as Argentina, Brazil, Colombia, Egypt, India, the UAE, the UK, the US, and Russia. Even some sighted and low-vision persons got in on the action in Brazil, Egypt, Germany, Latvia, and the US. So it was very nice to have a chance to work with that remarkable group. A second key deliverable was that everything we worked on was free and open source, including documents, so it all remains available for others to build on.
Specifically, we either created from scratch, or made large contributions to, the following:
Letícia F123, high quality speech synthesizer for Brazilian Portuguese: https://F123.org/leticia Fenrir, command line screen reader: https://github.com/chrys87/fenrir DragonFM, command line file manager: https://github.com/chrys87/dragonfm MHWaveEdit, graphical sound editor modified to use SoundForge key bindings: https://gti-nadolny@bitbucket.org/gti-nadolny/mhwaveedit.git Mishkal, a diacritizer for Arabic which is now 3 times faster: https://github.com/chrys87/mishkal
As well as some contributions to eSpeak-NG, plugins for Orca and Pluma, and BASH scripts that facilitate WiFi configuration, new user creation, security settings changes, and voice, language, and keyboard layout switching.
Please note that our team has moved on to new activities, so we will not be able to offer guidance on any of the above. Depending on your interest, you may find a helping hand at the Stormux list or one of the many other Linux lists around.
Lessons learned include:
- No matter how many resources you have, you are better off cooperating with an existing established project.
Many will disagree, as I also did in the past, but I now have learned that we are better off improving the applications where we spend most of our time (reporting and fixing bugs), instead of spending so much time and effort on simplifying installation. This will seem self-evident to some, but it is far from it for a technical crowd.
We would have been better off had we worked on a BASH script to improve Fedora or Ubuntu Mate for use by the blind, instead of creating something almost from scratch, as we did creating a script to build Arch for ARM computers.
- We should stop making blind-specific distros, and improve existing generic distros.
Again, the techies will disagree, but my concern is improving the experience for the 99% who does not know how to compile code, etc. This is also something that hurts to admit, but I learned my lesson.
The key is not starting a project, the key is figuring-out how to keep it going. My ideas in this regard did not work out for various reasons, and because I was not building on existing distros, but creating a lot almost from scratch, a lot of effort got lost or almost got lost during the ups-and-downs of funding.
Please note that when I say "from scratch", I do not mean that literally and technically, but I try to convey the sense that our work could have been more modular and portable across Linux variants.
This might be one lesson which blind techies might be prepared to accept, as so many blind distros have come and gone as soon as the main techie behind each distro runs out of energy. We cannot depend on a single super hero or one major funder, as sooner or later, for good or bad reasons, the projects falls apart due to that dependency.
It is of course faster and more fun in the short term to create one's own flavor of Linux, and this is why so many fall into this trap. I am not sure that I have the energy right now to try to convince anyone for whom this is not self-evident, but I am sharing this for those who are open to this suggestion: Do not create your own; cooperate with one of the major existing distros.
Here it is worth emphasizing that I had a very specific objective in mind, which was to make it incredibly easy for a non-technical blind user of NVDA to move to the Linux world. You may have objectives and interests which differ, and that is Ok, but, as I see it, these lessons are relevant to that specific goal. If your goal is for example, to have fun or just learn, or create a distro for advanced users, then some of these lessons may not apply to you.
Finally, another lesson that immediately comes to mind is:
- It is possible to provide a GUI-like experience, i.e. a good experience, on a Raspberry Pi 3B+ with Orca.
In other words, it will not be fast, but it will be usable. The key here is to use RatPoison and not the full version of Mate.
A related finding is that, if your focus in the console, no matter how good your developer is, he or she will not be able to implement simple GUI-like keyboard behaviors (like holding down Shift to select, or doing Ctrl+Home or Ctrl+C/Ctrl+V). Yes, some of those classic combinations might work out, but not enough of them to make migrating to Linux easy for a beginner.
In other words, Fenrir was incredibly fast and customizable, just not able to provide us with a GUI-like experience on applications like Nano, Mutt, and Nice Editor (ne), because of console interface conventions which could not be changed.