The project I'm working on at the moment wants to use the software we're working on as an opportunity to homogenize the use of certain terminology across the whole organization. (To give you an idea, we had about ten different terms that would refer to two different things and sometimes the words would overlap).
We ended up (or actually the client ended up making up his mind), defining a unique term to represent Object A, and Object B. But they happen to be too large. Something like "Extremely Large Object Name" and immediately an acronym spawned: "ELON".
In some places of the application we can afford to call the ELON, Extremely Large Object Name because the screen real state permits it. But other screens have a lot of controls and naming the ELON by its full name its just inconvenient.
I'm a big advocate for visual design and consistency, but I can compromise. I suggested using ELON when Extremely Large Object Name just wouldn't fit (with an appropriate onmouseover() tooltip). But there has been dabate about it.
Some people say, name it ELON everywhere, which I don't consider appropriate, since the application might be used from time to time by people that don't know what the acronym means.
Some other people say, name it Extremely Large Object Name, which is verbose enough to hint the user what the field does, but that is likely to break the templates that we have.
How would you come about it? Is there any Information Architecture philosophy around the use of acronyms within applications and its relationship with how acquainted the users are with terms? (i.e. if the user doesn't use the application often, they might forget what the acronym meant).
Hopefully this makes sense.