A new model for handling input Export

@article{citeulike:1031635, address = {New York, NY, USA}, author = {Myers, Brad A.}, citeulike-article-id = {1031635}, citeulike-linkout-0 = {http://portal.acm.org/citation.cfm?id=98204}, citeulike-linkout-1 = {http://dx.doi.org/10.1145/98188.98204}, comment = {Reconceptualizes interface elements (ala mickey) in terms of their input characteristics (one of the first if not the first tool to think about structuring input as something to deal with at the toolkit level) basically after that, it's a single structural choice and a bunch of library elements starts to move beyond uims (doesn't specify look \& feel without allowing it to change) not modal understanding this contribution is helped by understanding the model-view-controller: basically, another mistaken assumption of the past (beyond the automatic generation is ok thing) is that the look (view) and feel (interactivity) of an interactor are separable interesting features: multiple devices; abstracting input into a single model (pros and cons -- subarctic version); lapidiary (gui interface constructor) Approach is two fold - specific interactors are parameterized in very practical, interactor-specific terms - input is handled by a single state machine that works in every interactor lacks the elegance or simplicity of dourish/subarctic. Question is, will it do alright when something unexpected or new comes along, and would something that was first philosophized and less practical do better or worse? unusual feature at that time: supports debugging (lapidiary also unusual) }, doi = {10.1145/98188.98204}, issn = {1046-8188}, journal = {ACM Trans. Inf. Syst.}, keywords = {abstraction, behavior, cs-mini, encapsulation, hcii-minis, input, interactor, model-view-controller, reusability, tools, uims}, month = {July}, number = {3}, pages = {289--320}, posted-at = {2007-01-09 17:07:09}, priority = {0}, publisher = {ACM Press}, title = {A new model for handling input}, url = {http://dx.doi.org/10.1145/98188.98204}, volume = {8}, year = {1990} }

TY - JOUR ID - citeulike:1031635 L3 - citeulike-article-id:1031635 IS - 3 JF - ACM Trans. Inf. Syst. SN - 1046-8188 AD - New York, NY, USA EP - 320 TI - A new model for handling input PB - ACM Press VL - 8 SP - 289 KW - abstraction KW - behavior KW - cs-mini KW - encapsulation KW - hcii-minis KW - input KW - interactor KW - model-view-controller KW - reusability KW - tools KW - uims N1 - Reconceptualizes interface elements (ala mickey) in terms of their input characteristics (one of the first if not the first tool to think about structuring input as something to deal with at the toolkit level) basically after that, it's a single structural choice and a bunch of library elements starts to move beyond uims (doesn't specify look & feel without allowing it to change) not modal understanding this contribution is helped by understanding the model-view-controller: basically, another mistaken assumption of the past (beyond the automatic generation is ok thing) is that the look (view) and feel (interactivity) of an interactor are separable interesting features: multiple devices; abstracting input into a single model (pros and cons -- subarctic version); lapidiary (gui interface constructor) Approach is two fold - specific interactors are parameterized in very practical, interactor-specific terms - input is handled by a single state machine that works in every interactor lacks the elegance or simplicity of dourish/subarctic. Question is, will it do alright when something unexpected or new comes along, and would something that was first philosophized and less practical do better or worse? unusual feature at that time: supports debugging (lapidiary also unusual) AU - Myers, Brad PY - 1990/07// UR - http://dx.doi.org/10.1145/98188.98204 ER -