What's a better term for database "front-end" vs "back-end" for non-technical users?

Question

I routinely develop small data collection systems for a variety of purposes. One issue I frequently encounter is what to refer to the front-end as to users. They're just about tech-savvy enough to know that the database is the actual data storage and not the form they input into, and there's some separation between the two, but not quite tech-savvy enough to understand what is meant by 'front-end' vs 'back-end'. 'Database' is frequently used to describe either.

Thus, there's real ambiguity over usage of the term 'database' - a question frequently raised by both sides of communication is whether 'database' is presently being used to refer to the "forms where you/we type things in", the "place where the data is stored", or the whole system in general. It gets even worse when users insist on referring to Excel workbooks as databases too (and even, once or twice, the stack of paper on their desk - it's happened!). Confusion and/or heavy-handed explanation ensues.

So what's a nice, entry-level and generally understandable term to be able to say "these are the changes I've made to the front-end" and "these are the changes I've made to the back-end"?

Edit: I've tried using "form" to refer to the front-end, but that also leads to overlap, as users often think of the "form" as being the physical paper sheet they're copying into the system. So if I say I've made a change to the form, users tend to think I mean the paper form, not the front-end.

Answer 1

The terms I commonly mention with the users are interface and database. Most users know the term User Interface (UI) and even if they don't I find it more immediate than front end.

With database I mean both the DBMS and the server side code.

Most users know or understand this (they realize there must be some server side code) but they don't care. For the ones who don't know or understand it doesn't make sense to differentiate betweem DBMS and server side code.

Answer 2

Front end -> User Interface (UI) or Client Application

Back end -> Server

I think that most technical and non-technical people would understand what you were referring to using these terms.

Answer 3

The stuff you see

The stuff you don't see

Crudely over-simplified, but that usually works if someone is fully ignorant on the subject. They probably aren't going to grasp much more nuance than that if they're struggling with the word "database."

Answer 4

To be honest, it seems like you are trying to introduce a lot of ambiguous terms instead of sticking with the obvious front-end and back-end (where it is necessary to refer to them).

The key thing you seem to be missing though is that usually the user doesn't care where the changes have been made. You should describe things in terms that are oriented to them not the system. Eg. "I have changed the functionality", "I have changed the interface" rather than "I have changed the database/form".

Don't try to educate the user to your system, put it in their terms. For example unique nicknames for specific pages or forms often work better than calling it "the form".

Answer 5

Super high level verbiage for this:

Front-end - Consumer facing

Back-end - Internal

Answer 6

Front-End -> Users, Human Interaction like Webpage, I want to be able send an email. Back-end -> What happens when the email is sent, database. Where does the message go?

Database: Is never a front-end term. You may have front-end tools to interact with the database, but in your context it is back-end logic and storage unit.

Answer 7

If you have client software - front-end, and server software - back-end, so somewhere in your client application is connecting client to server and user know that connection should be established. How do you describe to user where is he connected to? You need some name to this entity. So, what is its name? Once you name it, e.g.: server, remote storage, database, central warehouse, headquarter and even back-end - you have to use this name to distinguish where you made your changes. But one of the answers already has very good point - user doesn't care usually about such things - he need his application to work regardless of front-, back-, side-, up-, bottom- and any other ends :-), that's all.

Answer 8

This is obviously a very good question as so many people are getting this wrong. :) The Server that the UI talks to is still the front-end. The question is if the server has been designed properly and split into 2 servers - a proper FE and BE. Some answers above are close. FE = the stuff you see or the server that creates/manages the stuff you see. BE = The rest. the server that handles the workflow/processing/crunching/...