Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

A recent discussion on here about whether or not program windows should still be called screens or if we should have improved terminology got me thinking... Dangerous I know! People as a whole tend to be fairly resistant to change. We get comfortable in our niches and used to the way things are. While some changes lead to good results and improve our lives or the way things are done, others are clearly not enough of a change or overall bad and not even worth attempting. What guides can we use as we program to determine if an improvement (whether it be to coding style, terminology, user interface, language use, etc) is really an improvement or not? I'm sure to some extent nothing will replace the try-it-out approach but are there any tests or guides that can be used to eliminate certain ideas that would eventually turn out to be worthless or a waste of time to pursue?

EDIT: For anyone who is wondering the discussion that brought this question up in my mind is found here: Does your organization still use the term "screens" to describe a user interface?

share|improve this question

closed as too broad by MichaelT, GlenH7, durron597, Yannis Jun 2 '15 at 8:00

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

up vote 1 down vote accepted

That's a broad question - I think there would be different criteria for each of "coding style, terminology, user interface, language use" and there's not a one-size-fits-all even within a given category. So I think you've actually asked at least three different questions here.

On the specific question of terminology: I think users of specialized systems come up with their own terminology based upon their understanding of the system. If they want to refer to what they see on the monitor as a screen, I'm not going to make a big deal about it, because I don't think it matters what they call it, as long as they understand what it does and how to use it.

So, the criteria in this case could be "Does forcing the users to use a given terminology improve their understanding, or the usability of the system?" If not, then perhaps we should be prepared to maintain a concordance of user-terms to our preferred developer terms (or "standard terms" where they exist) or just use the terms the users use.

As developers, I do think it benefits us in communicating with each other to use standard terminology in describing things. However, from reading the thread you referenced, I don't see any real consensus on what that would be in this case. In the specific case of "screens" it may not be all that important since we all seem to know what is meant by the term.

share|improve this answer

I'm assuming by the question, there is reluctance to your desire to change terminology. If so, what is the purpose in changing terminology ?

Terminology is important to a team. It insures team members can effectively communicate. Using the "right" words may only matter if the team is communicating with people outside the team. Even then, you often have to explain the terminology to the outsiders.

Things aren't as simple as screens any more. While there may be an initial state, screens can change dramatically based on user actions or other properties. Floating components, adjustable panes, expanded/collapsed components and even animations are all taking place within a visual environment.

Even with all of these richer components, we still need to provide users with a frame of reference to allow them to navigate the application. Those frames of reference may still be called screens, base screens or some other permutation.

Our organization tends to still use screen, though we occasionally use the word view or pane depending on sizing and context. In our application, screen components can be reused in a multiple window environment as well as a single screen view. It leads to interesting communications that are more often solved with sketches than words.

share|improve this answer
You are correct... in my opinion as I expressed on that strain I still feel that screen is a viable term. That post got me thinking though in more general terms if there was a way to determine if filtering test/guidelines could be used to weed out bad ideas for proposed change of any kind (not necessarily just terminology) from those that are good. – Kenneth Mar 20 '11 at 16:08
@Kenneth Maybe I'm missing the point of your question and thoughts, but it seems incredibly minor versus the goal: Writing rich and functional user interfaces. Your commentary doesn't seem to associate a problem related to the goal. Unless this isn't your goal and this is purely an academic exploration. If so, it really doesn't matter what people use or do. Things like terminology will continue to evolve as the art and science of UI design and implementation evolves. – Jim Rush Mar 20 '11 at 19:27

Not the answer you're looking for? Browse other questions tagged or ask your own question.