Essential input elements of a gui toolkit

Question

I am in a process of designing a new toolkit for mobile devices (as a part of my Master's thesis). I would like to know if there is some theoretical backgroud (researches, books, tutorials, etc...) to what a toolkit should contain.

Intuitively, things like buttons, input fields, sliders, switches, etc... should be there. But why? It would make me uneasy to just write these things in my thesis without any reference.

Answer 1

I hope I have the right end of the stick as to what you're asking...because I'm about to blab on a bit here!

Different elements of a user interface have different specific purposes, each of which aligns with a task that the user needs to be able to do (typically using their fingers), and they make that task simple and easy. They usually provide affordances through appearance or familiarity with similar controls on a user's experience or culture.

So for example, a button allows the user to make a single action via a simple touch. Without reading your mind, or understanding your speech (perfectly and unambiguously), it doesn't get much simpler than that.

Next is a switch/checkbox/toggle type control whose purpose is to change the state of something - usually between two options like on or off.

Then there's limited multi choice elements where more than two options are required - say half a dozen options in a radio group, combobox, dropdown, menu etc. Of course these are built essentially out of the button elements - just grouped efficiently.

After that, there's fields that allow you to enter one of very very many options that usually consist of numbers or words. If it's numbers that lie in a range, then sliders, spinboxes etc will suit the bill, and if it's text based, then that's enabled by single or multi line input fields.

So you can see where I'm going here I hope. Different elements of an interface allow different types of inputs from 1 action, through 2, a few, many or nearly infinite variations of input depending on the task involved.

That's why these fields are there - they have evolved over decades to be the simplest mechanism for each variety of individual input. Of course, sometimes their use in conjunction with each other can become complex, and sometimes the controls are built awkwardly, or are over engineered or simply misused. But these are 'bigger picture' design issues and do not affect the efficiency of each individual control.

When we build more specialist applications, complex interfaces, or fancy interactive visualisations, we are still essentially using these basic ui building blocks as appropriate for the complexity of the input at each indivisible point of interaction.

And they don't just originate with some Adam and Eve of GUI design. As with so many GUI related mechanisms, the basic elements translate from real world interactions long before computers were around - buttons, knobs, switches, dials, ratchets and levers were the mainstay of machinery control since the start of the industrial revolution.

They are like the periodic table of user interface elements. Indivisible building blocks for breathing life into a rich user experience. How romantic is that!

Answer 2

The first cohesive computer GUI was developed at Xero PARC and there are books that describe the development of this quite well and would give your a good grounding of early GUIs and their history. The most comprehensive is "Smalltalk 80 The Language and It's Implementation" by Adele Goldberg et al. ("Smalltalk 80 The Language" is a later version with less info.)

Following the release of Smalltalk in 1980 a number of GUIs emerged and evolved. The invention and refinement of GUI elements filled needs discovered in the use of the previous generation of GUIs. Another driving force for the creation of new elements was a market driven "arms race" where the creation of a new features were hoped to increase market share.

All in all it was an evolutionary process in which successful elements survived and were copied while less successful elements became obsolete (the pie menu was one kind of element that didn't survive the cut).

As to the original question, "what should a inputs should a GUI toolkit contain?" understand the answer is a moving target. Apple documents the iOS elements they provide, but there are tons of custom elements created by developers (a fast moving target), so I don't know exactly what you'd want to include in your survey.