UXDB: Introduction and A Call for New User (Input) Forms
By: Lesang Dikgole
Tags: Java, Programming, UX, Database, Forms

I wrote an essay several months ago, complaining that our database models are insufficient and horrible.

To address this problem, I have been working on a side project that aims to challenge all the current UX, DB and programming approaches as most programmers have come to know them.

Java, I Personally condemn You to Hell, with All Your Friends

Part of it is personal. Since learning to program (it all started with Pascal back in 2001) and being exposed to computers at a rather ‘late age’ of 15, there are very few things that come close to revolting than three things I have observed in the computing world:

A. UX designs that clearly pay little or no attention to the ACTUAL, not the imaginary user. Ever since being introduced to computers, I have always hated companies like Microsoft, and Google. Apple is actually not that much better; it is just that I have not had enough exposure to Apple products to make up my mind. The issue with UX, for me, has never been that it “looks pretty”. It has always been, does it work for ME? Even Job’s matra of ‘design is how it works’ doesn’t fairly capture the concern I have always had with the prevailing UX design approaches.

B. The entire concept of the database. My first experiences with databases was with tools like Microsoft Access. The entire experience was nothing short of brain-numbing. It was probably 16 years ago when I first had an experience with a database. It was appalling. (Let us keep in mind that my love for all things computers, computing, and programming was already on fire back then!) I vividly remember trying out my ‘new’ database table with Names, Surnames, phone numbers, and some other random field. My goal was to ‘test’ the database by scripting some Excel program that imports those Database entries into Excel. Just fooling around, really. The shock and horror of learning that if any of the ‘cells’ in any of the rows was ‘missing’ an entry, the entire ‘import’ script would return garbage! (I began strongly disliking the ‘garbage in, garbage out’ phrase right then and there!)

C. Java! And anything that comes close to looking like it! OO, objects, classes, UML, interfaces, and packages… It appears they were ALL invented with one goal in mind : to dis-empower mere mortals into building the next and better Microsoft, Google, Apple and company. My first introduction to programming was nothing short of happy, glad, and joyful. I built a sizeable number of Mathematics ‘procedures’/functions/methods using ‘lil old Pascal! In came the horrid Java, with all its insane ‘public static void main’ stupidities, and I henceforth refused to aspire to be the next Bill Gates again! In University, I had the most fun doing firmware and embedded code. It made me run away from all the universal madness of OO and its heavily sedated loyalists.

UXDB

Defective Approaches

The truth is, we have several defective concepts that are not helping programmers and computer users to move forward in terms of advancing our UX and DB approaches. Here are several of them:

The MVC architecture. Seriously? Who seriously thought this approach should be made Universal?

The Server-Client approach. C’mon! Is IBM still secretly ‘running’ our computer-terminals that we need ‘servers’ for every single program?

‘running’ our computer-terminals that we need ‘servers’ for every single program? The ‘back-end’/database. See previous.

‘The user should not change the program’. I blame Steve Jobs for this one. Bill Gates never had a single original idea himself…

That’s a wrap in terms of defective approaches.

UXDB Approach

The UXDB approach is NOT a ‘variation’ of the above approaches. It is NOT about ‘UX design’/MVC or ‘Database design’, etc…

It is unfortunately (not yet, anyway), not even a new programming language.

But it comes close…

UXDB is:

About programmatic/database-centric UI

User-centric approaches to database design. Huh? Yep, pretty much.

There have been similar approaches in the past to ‘realise’ this. Programs like MATLAB, and the REPL as experienced in LISP, Python, Clojure, come extremely close to achieving this.

The most glaring omission in these similar approaches is their lack of emphasis on data storage, retrieval and management. Their GUI/UI approaches are fairly primitive as well, but they can be ‘modified’ by the programmer/user as preferred.

UXDB : The Call For New User Forms

UXDB: Views

When it comes to user ‘Views’, a resolution of sorts exists (in my mind at least) as to how a UX can be made adaptive but functional. The Unix/Linux terminal, is, believe it or not, quite effective. The only thing ‘missing’ in the Unix/Linux space is the ability to dynamically launch personalised screens and modify them and their related data or text on the fly using the terminal itself.

That future should not be that hard to imagine or realise. But the Apple’s and the Google’s have made us think thus!

UXDB: Inputs

No one wants to ‘go back’ to the old world of CLI-driven horrid ‘question and answer’ paradigm (qAp) of providing user inputs to a program. But, to be honest, the computing world has surely regressed since qAp was introduced. The qAp system actually has some intelligent things built into it, like checking if the user inputs are valid on the fly as opposed to ‘submitting’ a whole form only to realise an entire 10 pages later than you missed a ‘field’ and now you have to go back and ‘re-fill’ the whole thing AGAIN because the darn stupid web-page didn’t cache your previous inputs!

My ‘UXDB’ project does not yet have a clear resolution to this dilemma of user inputs. The qAp system was clearly a bit too rigid. But our modern user forms are clearly much worse.

We could, however, observe some contextual issues about dealing with User Inputs:

Like my first experience with a database, there is nothing fun about ‘entering’ a form. As db-engineers in most enterprises know, users rarely even bother to ‘double-check’ if they are entering the ‘correct’ data.

about ‘entering’ a form. As db-engineers in most enterprises know, users rarely even bother to ‘double-check’ if they are entering the ‘correct’ data. Because current ‘database’ designs are not user-centric, the ‘User Form’ UX designer is usually forced to ‘comply’ with the database structure, above and beyond whether the User likes that database structure or not, or even whether the User will actually enter the correct data or not.

This provides us with some basic heuristics we could use for dealing with user inputs in an application:

Never let the ‘database’ dictate what the user inputs/form should be or look like

let the ‘database’ dictate what the user inputs/form should be or look like Make the ‘input process’ as painless as possible. Drop-down menus are actually a rather decent innovation. They just don’t work for things like entering a name or one’s favourite dish.

the ‘input process’ as painless as possible. Drop-down menus are actually a rather decent innovation. They just don’t work for things like entering a name or one’s favourite dish. Make the ‘system’ work without any user inputs. The idea that a program is to stop working due to a missing user/system input is frankly ridiculous and should be done away with, immediately . As any experienced programmer would know, this is a language-level problem. If your programming language has a heart-attack every time it sees a ‘null pointer’… the poor programmer will clearly not live long too!

the ‘system’ without any user inputs. The idea that a program is to working due to a missing user/system input is frankly ridiculous and should be done away with, . As any experienced programmer would know, this is a language-level problem. If your programming language has a heart-attack every time it sees a ‘null pointer’… the poor programmer will clearly not live long too! The User should be able to ‘programmatically’ alter the input/form process

the input/form process Data sharing between programs should be made easier. This is a little harder. It involves a bit of security re-design. OS-level ‘user-identification’ systems like FaceID will undoubtedly make this a little easier in the long run.

between programs should be made easier. This is a little harder. It involves a bit of security re-design. OS-level ‘user-identification’ systems like FaceID will undoubtedly make this a little easier in the long run. Program independent user inputs using open data format files like JSON, XML, etc

These are merely ‘structural’ heuristics. We clearly need more refined examples and layouts on how to proceed…

Transactional Anarchist

Related Stories from DDI: