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

[ledger-smb-users <..hidden..>]

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.

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

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

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

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

ario



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