The way I got over that barrier to entry was to consider each line of code as conversation. That is, I treated each line of code as a specific line in a conversation.

A lot of languages have a lot of bloat involved that only makes sense after you’re a beginner. That’s unfortunate, because it only makes it harder.

As such, I found that talking out what I want the program to do made it much easier for me to conceptualize what I needed to do.

if (something) then do thisThing;
else doSomethingElse;

while(thisThingIsTrue) doSomething;

Function/Method calls are a little tricky at first, but really they are short hand for a bunch of code. So, you could have:

boolean someFunction() {
if (something) return true;
else return false;
}

if (someFunction()) doSomething;
else doSomethingElse;

Method calls within objects are just an extension of that. Let’s say we have a Pirate class that has the function someFunction().

Pirate{
boolean someFunction() {
if(something) return true;
else return false;
}
}

Then we could say something like:
Pirate p = new Pirate(); //I just created a new Pirate.

if (p.someFunction()) doSomething;
else doSomethingElse;
}

An example of what I mean is IxD people can work on systems with abstracted information much easier than IAs (Smart Houses for instance), all they need is things that interact with other things.

However, that being said, realistically the terms seem to be selected by whatever the individual thinks sounds cooler, and not by the practices that

Also, food for thought. Isn’t it a bit fascist to believe we can control a users experience?

Though I thoroughly understand your concern, I think there are things at play that need to be considered.

First, your concern with exposing the underlying information model. Suppose we expose the entirety of the information model to the user, what will your average user be able to do with it? The idea behind an aggregator is to abstract the user from the model and simply immerse them in data that is collected for their convenience. Signposts are intended to lead the way to the information you want, not add complexity to a system that was just simplified.

To impose the requirement that they understand where all data is arriving from could undermine the useful nature of some sites. Consider a website that aggregates reports for users on a corporate intranet. Would it be more useful for the average user to know which reporting system compiled each piece of data or is it more useful for the user to have an aggregated dataset they can use for reference?

Let’s consider an even more challenging case. Suppose the data is aggregated and presented in a visualization. In this case, to present all systems and associated data would defeat the very purpose of the visualization, making it less readable and less usable.

On the other hand, if we consider usability and content continuity, I don’t see any reason that this proposal of incorporating signposts necessarily excludes your concerns. I think you’re a little more concerned with core function and site content than site signposts. Perhaps the solution to your concern would be better transparency in site function and architecture than attempting to clutter the site with “signposts” that are really reference markers and footnotes.

A key limitation within silo’d systems meant that when I was working with personnel I had to be connected to and logged into my HR portal – be that SAP, PeopleSoft, or what have you. Therefore I had an intuitive understanding of the source which provided the data I was interacting with.

Now I may be working on a portal site, interacting with personnel data, but I have no idea where the data is coming from, how fresh the data is, nor whether changes to it will be reflected back to source systems that I mean to impact. There is a great risk of breaking the trust as we push data further and further from the source systems into dashboards and mashups.

At the same time I get client requests demanding data, reporting, and features be implemented in the user interface for which there is no source and possibly insufficient granularity to provide. Business intelligence tools in particular expose the limits of how data is stored and reference when the user experience fails to provide meaningful reports because data domain concepts do not match implementations. Explaining to the business that a personnel list cannot definitively identify the difference between employees and varying types contractors because insufficient metadata is captured during onboarding is definitely a non-starter of a conversation.

So – Yes to road signs! But let’s also talk about road signs and markers that are expressed between the user experience and the business information model – and how those elements should be expressed as part of the design process to drive the interesting discussions that lead to solutions or drive alternate approaches.