English Boards > V3 Development

Are the Rules getting too complicated ?

(1/3) > >>

JohnS:
Looking at the features of V3 to V2, I (and this is my opinion) think the Rules are getting too hard to setup to use features like Ticket/Order States.

What I mean is maybe we need to look at the Rules themselves and make them more flexible and remove some of the guess work.

1. It is hard to know exactly what variables are available to each rule, so maybe add a legend (like Printer Templates) showing what information can be retrieved when using the selected Rule.
2. Instead of having fixed Constraints, have a drop down list of variables to select from. Have an 'Add' button to add more constraints
3. Expand the expression list from =, !=, ?, etc to also include other common expressions like
 - Starts With
 - Ends With
 - Is Length

Ticket and Order States needs to be more readily available within Rules as especially Ticket States can remove the need to use some {:Settings} variables and eliminates the issues with retaining Ticket/Customer data when closing and re-opening tickets later, like Customer Discounts on specific items.

emre:
I completely agree! I'm about to release 3.0.17 so our base theme for 3.0.18 can be refactoring automation. I'll focus on this.

emre:
First step of improvement is supporting printer template tags inside rules so instead of using expressions we can read ticket or order data with printer template tags. I hope it will simplify things because we are familiar with them. This feature is done!

Second step will be adding custom constraint lines for building expressions like {TICKET TAG:Blah} = ABC. It will work like current rule parameters but as you suggested we can type values in left part and we'll be able to type template tags :) I think that will improve rules a lot.

Stelzi79:
The real problem is the lack of documentation and the multiple steps to implement a feture with Rules, AutomatiationCommands and Actions. If you need also setup up Account- or Warehouse-Transaction it gets even more complicated and undocumented. For example to fully implement a sane Tax-handling you need to do 5 additions or settings in different areas of Settings and without setting Account-Transaction doesn't even begin to work which isn't realy clear in the beginning.

 I've an idea to implement and Template/Wizzard type of system where you only configure some smal details and the wizzard configures the rest and points you to additional setting you may have to do. Such a Template/Wizzard-System would make it realy easy to use all the powerfullness of SambaPOS.

emre:
Yes I agree and I'm aware of the situation. Especially it is hard for V2 users.

Our real power is the simplicity. V3 is not easy to configure yet but simple. Once you get the idea it gives a lot of possibilities. We have a lot of small pieces that needs to be connected to build something. Before adding a feature I'm thinking twice (even more) if it can be done by using current features. If so I don't add additional features. That creates an abstraction and this is the reason of the complex configuration.

Look how I removed payment buttons and used automation commands instead. Ironically instead of writing code I've deleted code to implement the request and the reason of that change was the settle button. As you know we are using portrait mode for handheld devices and one of our users asked to disable settle button on tablets. Uh? In fact it can be solved easily by adding a simple setting to disable settle button but I know this is only the tip of the iceberg. They'll want settle button for managers or some people just don't want it at all. This is already possible with automation commands because of the wide mapping features so instead of adding that simple setting I've deleted whole code and switched it to commands. As a result of that code removal we gained bonus features. For example we can disable settle button for specific ticket states to implement proper workflow. Of course some users complained because of this change because creating a fast payment button was a single click. Now it needs a lot of configuration. I know it....

It can be easier with tooling as you suggested. What we need to do is just auto generating required data.

We used similar idea for menus or other areas at "Batch Create XYZ" screens. For example a "Batch Create Tax" tool can create required account templates, accounts and transaction templates from entered Tax Configuration lines. Instead of wizards I thought tooling should be text based so it can be shared. We are using this text file idea for generating default menus and tables on installation. That just needs improvement. At the end we can have a single text file for whole configuration. Even for rules, actions etc.. This is what called as DSL. You can read more about the idea here http://www.primaryobjects.com/CMS/Article127.aspx

However my current priority is the infrastructure. When I add features for ease of use before finishing the infrastructure I have to delete it later so that creates waste. Before implementing hammer I have to be sure nail works fine.

I hope we can have little more development, financial and social power to implement all ideas quickly, generate documentation and of course influence people. I don't like having undocumented code, undocumented features and a lot of missing other things too. When I first started SambaPOS I decided to give priority to "requests". We have thousands of installs but for me real SambaPOS user count is not more than 20. I thought if I can solve their problems I can solve everybody's problems. As a result three years of community interaction brought us here. I don't know yet if it was a bad idea or not but I believe we're still on the right track.

Sorry for the long post. I thought I have to explain my thoughts so we can create better solutions. Thank you for reading it.

Navigation

[0] Message Index

[#] Next page