Re: Many hands make light work: what can we do to get 10 minutes of your time in 2016?

On Sun, Jan 3, 2016 at 11:27 PM, ledger-smb-users <..hidden..> wrote:

On Sat, 2 Jan 2016 17:28:47 +0100
Erik Huelsmann <..hidden..> wrote:

> Hi ario,
>
> Thanks for taking the time to provide some background on your earlier
> feedback!

Actually you're most welcome. I've enjoyed the encounter with LSMB and
with Chris and you and appreciate the work 'the team' is doing in the
open source realm--even it's on a business basis.

> On Fri, Jan 1, 2016 at 2:52 AM, ledger-smb-users <
> ..hidden..> 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.

That's not what I meant, but that would have served the purpose at that
time.

> 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.

I totally agree with the desire for efficiency in entering data, and
that's another point that influenced my decision: it just wasn't going
fast enough.
On the other hand, maybe a sort of 'impact counter' would be helpful.
If the number of transactions that are going to be affected reaches
some threshold, ask user whether he's really sure.

> 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?

No, the 'repair' was to be done in the database itself with postgresql
commands only. That scared me.

> > 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?

The problem that I can't look 'inside' the database and get a
comprehensive view on the data itself and repair it if I 'can see'
where is the problem.

Today you can:

1. Reverse an errant payment via the UI properly

2. Reverse an errant invoice or transaction through the UI properly.

3. Delete pending batches and drafts if they have not been posted to the books.

As we tighten up db constraints, we will still likely see a few cases where resolving issues through the db is necessary but we have been trying hard to prevent this as a primary means for some time time.

Erroneously entered data today should never require dropping to the db to solve.

However, we are occasionally finding cases still where misconfigured systems can enter inconsistent data. Until we get the financial logic moved and the db structure underneath redone, this will still be an (increasingly rare!) issue.

> > 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)

You don't really need me back but if the current 'solution' turns out
too slow and lsmb has improved in that aspect (and the other one) it
might happen automatically.

> 2. Can you tell us the name of your current solution? Is it Open
> Source software too?

Yes it is. I don't think it's fair to advertise other solutions in this
forum, so I'll inform you separately.

I appreciate your sensitivity on this but in the context of this discussion, but in this context, feel free to discuss it.

> After all, we can't be everything to everybody, which means it's
> definitely good to have alternatives to point people to.

Right, it's no problem.

> > 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 :-)

Your sense of humour is appreciated. :)

Actually almost every time we have seen this, it has prompted database fixes, so seriously.....

> > 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.)

I sense a tiny amount of friction here with the open source model if
not 'home use' but understand the rationale.

Well, Erik's sentence above covers a breathtaking scope in terms of what we actually offer.

The setup complexity for a basic system for a given industry will eventually get solved for some definition of "setup." THis could be done with vms or docker images, or better packaging. But if I understand Erik's points above that's a minority really of what we are talking about.

First, people will want some new templates or the like. Some of this can be improved as well. But design is design and that is not something you can just drop in regardless of the technology used.

But then we have things which are "setup" issues but are their own disciplines. If you are slightly larger, how do you tune PostgreSQL? Do you want backups? An ability to restore to a point in time if something goes badly? Where are these stored? Want replication? What then?

Then we get to emailing invoices. Here anti-spam best practices have changed a lot in the last decade Do you want to keep up with that? Then there are other aspects. Do you want training? Or is documentation and the email lists good enough? What about on-going support?

There are a lot of people for whom these extra burdens of running a system are really not very attractive. That is effectively where Efficito comes in.

Are we the only vendor here? No.

Do we want to be the only vendor here? No.

Do we want people to run LSMB at home? Yes.

Are we here to help? Yes.

> > 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!

And to you too.

Thanks again!

ario

------------------------------------------------------------------------------
_______________________________________________
Ledger-smb-users mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-users

Best Wishes,

Chris Travers

Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in.

http://www.efficito.com/learn_more