i was viewing facebook today and was annoyed by the space wasted by the facebook ad "offering" the option to move a facebook link to your home page. I don't want to do this, so i wish i could acknowledge that i have seen the ad and i now want my screenspace back. So i thought i would put a message on my facebook page complaining about it.
When it came to writing it, i wanted to be brief - concise would be good. I wanted to say -
I wish they would make that annoying sticky message about having facebook as your homepage into a notification message.
The adjectives sticky and notification have a clear meaning to me. Sticky describes a message which persists on the screen. Notification describes a message which remains on the screen until it has been acknowledged. Often this is an "OK" or "ACCEPT" button.
There is no succinct way to communicate about the behaviour of the screen. No way to describe how we interact with the screen. Because my succinct complaint was succinct to nobody but me, i didn't bother posting it.
But it did raise the question "How do we interact with the screen?"
From the Oxford Dictionary, to interact is to act reciprocally on each other
or to behave in a way that influences and responds to another.
I would say that data with which we do not interact is irrelevant. (We do interact with the falling tree in the forest - we just may not be aware of it)
So what is the data with which we interact?
In SQL, the lowest level of data is the column. That is the tangible data. Whatever we do with a table, we eventually access columns of data.
A column of attribute values is specified by -
Table Name
Ids (usually via selection)
Column Name
Attribute Values = SQL Select(Table Name, Column Name, Ids)
In an interaction with the user, attribute values are given by the user in response to a process' request.
Attribute Values = Get User Reply(Descriptive Prompt)
E.g. a program requires the user's date of birth
Date Of Birth = Get User Reply("Please enter your birthday")
Any programmer will immediately recognize that this sort of request allows the user to enter any sort of reply. The user could enter the name of the pet dog. Or the name of the hometown. Or anything. So a programmer would embed this request in code which ensures that it is a valid date. Or maybe somehow identify the request in the user interface as a date of birth, by some obtuse procedure.
A way of ensuring that the user interface knows what sort of data is expected to be returned to the requesting program would be to tell the user interface what sort of data is expected -
Date Of Birth = Get User Reply("Please enter your birthday", "Date")
Now the user interface can ensure that the data returned is a date. Good.
If there existed a list of attribute names containing each one's data type, another way of achieving this could be -
Date Of Birth = Get User Reply("Please enter your birthday", "Birth Date")
The user interface looks up a list of attribute names for
the attribute "Birth Date", and retrieves the data type from there.
While this appears a subtle difference from the previous example, it does have the advantage that the program's code now contains not just the message to prompt the user, but also the name of the attribute required by the process.
Uploading ....