* Robert Weiner <[email protected]> [2020-10-29 07:26]: > Jean, see my latest posting to the list. > > Personally, I don't relate to the idea of workflows very much.
If I want it or not, specific actions become necessity and then after a while one can see the workflow being formed and then extract it and repeat it. Example is group handling of communication with many people. Processes are known as CRM in computing, yet CRM as Customer Relationship Management is not really software rather set of methods on how to do it. Imagine that customer A have been handled by organization in last 10 years multiple times by multiple staff members. Customer may prefer specific sales manager to contact him. But new staff member comes and without looking into previous history with customer tries to push the sale on the customer, but it does not work. Would that new staff member look into history of any communication and notes related to customer that would not happen. He would maybe contact the preferred sales manager to contact the customer and get the sale closed. Or sales manager could introduce new staff member to customer. That example forms a workflow to always find previous or background information of a customer, verify all notes, and then to contact him. > sometimes you repeatedly do sequences of steps, as in Git commits. But > much of the time knowledge work requires inventing new ways of working or > extending old ones, so I focus on core capabilities that people can use in > creative ways as they see fit, in the same way all of Emacs' core > capabilities provide this same freedom. I agree. And I do not find it contradictory to workflows. Automated workflows work with computers only. With people one has to adapt to the situation. Above example also says that automatic calling of people is not desired. What if customer already purchased a product last week and new staff member is calling that customer to sell him that same product customer purchased? That could break relation with customer. If stuff member knows and should know that product have been purchased, then call could be about after sale product support. > You used the example of handling calls. For one call, you might look up a > contact, follow a URL reference, add a note with an implicit button, alter > the information on your screen and send an email. Hyperbole's toolkit > nature can help you in all of these respects but there is no definable > workflow in such a context, you have to create it from mastering a set of > primitives. Hyperbole simplifies this process by keeping the number of > concepts relatively small and making the computer do the hard work. Yes, I do not expect workflow from Hyperbole. What I would need would be buttons or way to bind buttons to buffer on the fly. You could give me pointers. I would not like making a special temporary director where I would be creating on the fly .hypb to enable buttons in such buffer. That could be last resort. When I enter ~/tmp directory there I have .hypb and inside is written that it belongs to buffer "README" and I have buttons in README and I can perform management functions. Even staff member could then perform computer management functions without knowing anything about computing commands. Somewhere after entering the directory or upon opening of a file you must have setup some hook, maybe hproperty:but-create or other hook. Help me. Then this hook is looking into .hypb and assigning buttons. Is .hypb then converted into some Lisp structure of buttons that buffer is using? If that is so, then I just need to find the name of list structure and I can already create buttons on the fly. Am I right? Additional suggestion: if the file is read-only and there are buttons, you could make TAB to behave in such manner to switch from button to button similarly like within eww. -- Jean Louis
