Ask HN: How would you write front end code for bookkeeping app? | Hacker News Reader

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

1 pointkrick1 comment

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'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'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't really see how should I organize and compile clojurescript sources, when I'm using pretty much unique js-code for each page.

Both users and developers often don'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'm writing stuff like that for quite some time now, but still have that feel that there could be some way to do it right, and I'm not even close to it.

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.

Reply on news.ycombinator.com