

Ask HN: How would you write front end code for bookkeeping app? - krick

A lot has been said about writing and organizing frontend code. Tools like grunt.js, clojurescript, all sorts of reactive libraries and all-in-one frameworks have been invented. But every time I see something like this discussed it&#x27;s mostly about rich-UI web-services, one-page apps, stuff like Netflix and such, but it is very different from what your typical back-office app. Clear UI is the key for the front-end site, but CRMs and such are notoriously known for their insanely complicated interfaces. One-page js-apps also don&#x27;t seem like a good idea here, as things are complicated enough without that and dramatic changes in UI happen on a day-to-day basis, not once in a while like on your front page. I don&#x27;t really see how should I organize and compile clojurescript sources, when I&#x27;m using pretty much unique js-code for each page.<p>Both users and developers often don&#x27;t really care about that, because business-logic is the king on the back-office side. But still, have you any articles that would talk about that or maybe you have some thoughts of your own? I&#x27;m writing stuff like that for quite some time now, but still have that feel that there could be some way to do it <i>right</i>, and I&#x27;m not even close to it.
======
Terr_
Some random thoughts from working on a proprietary intranet app that manages
proposals/jobs/billing and uses some single-page-JS sections:

1\. Some users want to have almost an in-browser spreadsheet where a change in
one text-cell ripples through dozens of causal relationships. If you choose
this, you need to fully commit to all the focus-handling / concurrency /
algorithmic issues (e.g. avoiding cycles) that it raises, and sometimes push-
back against certain things that just aren't practical.

2\. Assuming you don't take the tabular approach, consider task-based
interfaces, where there is information about what the user _wants_ to do and
you provide an interface that works best for that specific route. (As opposed
to "here's a whole bunch of facts, change whatever you want" approach.)

3\. Your experienced users will probably want to use tabbing to move between
fields for data-entry. You may want to make this an explicit part of the
design process, or else they'll get used to whatever the browser default is
and then fixing it later will break somebody's learned workflow.

4\. Carefully consider what groups of information people will want to enter
and then save as a unit, versus pieces where it should be saved on-blur or
automatically.

5\. If you do use on-blur to save data, make sure you have some feedback so
that users know when the field is still in the process of saving. Also
consider how to accommodate users who try to make a lot of rapid changes to
the same field.

