Emacspeak discussion list

[Victor Tsaran <vtsaran AT gmail.com>]

My personal take is that we can have both. I don't think it has to be one or the other. :)

I am largely comfortable with the way Emacspeak works today, but I would be equally glad if Robert's work can attract younger users who did not grow up in the age of Unix shells and such.

I can only admire Robert for his willingness to dedicate his time and energy to make Emacspeak more approachable!

Raman is correct though that any such user-friendly improvement may lead to an increased number of customer support requests. :)

But then again, perhaps not!

:)

On Wed, Apr 24, 2024 at 4:46 PM Tim Cross <emacspeak AT emacspeak.net> wrote:

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 .
Emacspeak discussion list -- emacspeak AT emacspeak.net
To unsubscribe send email to:
emacspeak-request AT emacspeak.net with a subject of: unsubscribe

--

--- --- --- ---

Find my music on

Youtube: http://www.youtube.com/c/victortsaran

Spotify: https://open.spotify.com/artist/605ZF2JPei9KqgbXBqYA16

Band Camp: http://victortsaran.bandcamp.com