I think the below statement from Raman is one which we, the emacspeak community, should note and consider. My own personal view on Emacspeak is that it is philosophically very different to most other packages out there, especially end user focused ones. Understanding this philosophical difference can be important as it helps ensure alignment between expectations and reality, which is a fundamental component of good mental health. I think of emacspeak as Raman's research workbench which he has made available to those who would like to use it. As such, I expect a system which is to some extent constantly in flux. I have no expectation regarding API stability, backwards compatibility or user support. I expect it will be necessary for me to investigate and resolve any issues I run into. I might ask for guidance or I might report an issue to see if anyone else has encountered something similar, but over all, I expect it is down to me to find a solution. I see my relationship with emacspeak as largely a symbiotic one. By using it, I get to experience the implementation of many of Raman's ideas regarding an auditory interface e.g. soundscapes, auditory icons, voice locking, spacial sound etc. In return, Raman gets feedback from users and important data points regarding various ideas, both from his daily usage and that of community users. In many respects, I find it beneficial to think of emacspeak as a prototype rather than a user package. It can be a little unstable, it is often a bit rough around the edges and can occasionally be a little annoying. However, often it enables me to do things that were near impossible with other solutions and often it surprises me with some new idea, concept or feature and above all, it enables me to work at a productivity level which was not possible with other solutions. I think Ken Bech's 3X model is quite relevant here. In this model, you have 3 stages explore, expand and extract. Each stage is typified by different characteristics. - Explore: This is the R&D stage. This is where I see Emacspeak as sitting. The focus here is on rapid prototyping of ideas which takes preference over stability and maintenance. - Expand: This is the performance tuning stage. You focus on how to make the solution perform well under load. There is little new idea experimentation. Instead, you focus on improving the performance of what you have. - Extract: This is the final 'product'. The focus is on stability, maintenance and maximising return on investment. This is the user level product. Understanding emacspeak is permanently in the explore stage will help in understanding what Raman's priorities are and why it is so important to keep a focus on research rather than maintenance and why adding functionality which might improve the end user experience needs to be balanced against the potential negative impact on being able to try out new ideas and implement prototypes. When I first came to emacspeak, I found the focus on research and possible consequences regarding stability a concern. Initially, I seemed to be running into issues every other day and I seriously considered forking the project and creating a version which focused on end user usability and stability. However, as my knowledge of Emacs, Elisp and emacspeak increased, this became much less of an issue. The reality is, while it may be challenging to get started, once you are started, maintenance is trivial. I soon realised that the effort to maintain a 'user version' of emacspeak simply wasn't worth it. > For me,Emacspeak is both my daily tool and also a research work-bench > of sorts, and I am therefore very careful to not turn into a mode > where I'm just maintaining a set of bla tools and end up stuck in a > least common denominator state .
|Full archive May 1995 - present by Year|Search the archive|
If you have questions about this archive or had problems using it, please contact us.