Hi ario, Thanks for taking the time to provide some background on your earlier feedback!
On Fri, Jan 1, 2016 at 2:52 AM, ledger-smb-users < ledger-smb-us...@infopower.nl> wrote: > That goes back some 1 or 2 years. > We have been discussing the problem at that time, so I'd like to refer > to that exchange, if you still can dig it up from your archives. > It must be in the public archives; maybe I didn't look hard enough yet, but I didn't find it before Chris responded. With the feedback below, I think we have a nice summary of the situation though. > It had something to do with marking a lot of accounts payable to be > paid, something like that. Things were marked paid by default upon > entering the screen. > Ok. Now I remember. I think you're right that it confuses many users on their first experience and it probably deserves to change. However, changing behaviour like that within a maintenance series of releases isn't a good idea. With the imminent release of 1.5, we have a good opportunity to change it though! > I think that was a bad design decision. It would have been better if > there were (maybe there is now) a button to mark everything, so at > least the user is asking for some action, and hopefully is conscient of > that, before pressing enter. Agreed. Thanks for pointing that out. > I just was 'assuming' pressing enter would > get me out of that screen as I hadn't filled out any boxes, commands or > whatever yet. > Ok. Basically, this statement calls to say that every screen should have a default "Cancel" button. While I don't disagree in principle, there's a reason those that many of the defaults as they are: many experienced users will want defaults which help them carry out their tasks quickly and efficiently. To that extent, <Enter> has not been bound to "Cancel" in many places. One thing you're making me aware of now, though is that we have almost every transaction go through the steps <Save> and then, upon review, <Post>. Payments are still missing that, I think. However, disaster was the result. :) > That's definitely an undesirable result, especially with novice users (because they probably don't know how to get out of the mess). > If I remember right, your response was something like, yeah, you get > that when you press enter in that screen and then offered some database > commands that might help, or should help, if properly entered. > Just as a way to estimate how we better help our users in the future when they come with problems like these, would you say that this response was not helpful, unexpected, not appropriate for your experience level? What better answer could we have given you? Some steps to go through in the application itself instead of on the database level? > That's where I realised that databases are nice, but if one doesn't > know exactly how they work and are built up, like me, then one can > seriously screw things up, beyond repair, diy-wise that is. > Would you have come to the same conclusion if Chris had given you steps to execute inside of the application? I mean, if he had done that, it would have been apparent that you could have fixed your errors without mega-advanced query wizzardry. Would that have made a difference? > So I went back one step and started using another 'solution' which > maintains the whole database in readable text. Usable for me, probably > not for the majority of the LSMB-users. > Ok. I think it's good to have alternatives; after-all, we can't be a solution for everybody. Two questions come to mind: 1. Is there a chance we can win you "back"? If there's a slight chance, what would we need to do to grab it? (I'm estimating the answer to be "no", though) 2. Can you tell us the name of your current solution? Is it Open Source software too? After all, we can't be everything to everybody, which means it's definitely good to have alternatives to point people to. > By now probably things have changed in LSMB in that maybe there is a > confirmation step now, but I'm sure I would find another way to > do something seriously damaging to the database. > Actually, it would be very helpful, if you did that :-) > Then there was the install procedure which was really some excercise in > self-torture for a diy-er... I'm happy to hear that things are going to > improve, or already have. > Right. There's a direct relation between this point and the incorporation of Efficito, which offers a hosted solution: there's a direct relationship between the complexity of the setup procedure and the desire to be not only an accounting system, but also to integrate invoicing, with PDF invoices, open item management, inventory management, fixed assets administration and so on, with the ability to mail customers and vendors directly from inside the system. (Although, granted, most users probably most heavily use the accounting side.) > Thanks for introducing me to accounting however, I learned a lot of > this experience.- > Thanks again for following up on your original feedback! Happy and prosperous 2016! -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.
------------------------------------------------------------------------------
_______________________________________________ Ledger-smb-users mailing list Ledger-smb-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-users
