Not Signed-In
Which clippings match 'Appropriately Complex Representation' keyword pg.1 of 2
22 JANUARY 2016

Humanities aren't a science. Stop treating them like one.

"I don't mean to pick on this single paper. It's simply a timely illustration of a far deeper trend, a tendency that is strong in almost all humanities and social sciences, from literature to psychology, history to political science. Every softer discipline these days seems to feel inadequate unless it becomes harder, more quantifiable, more scientific, more precise. That, it seems, would confer some sort of missing legitimacy in our computerized, digitized, number-happy world. But does it really? Or is it actually undermining the very heart of each discipline that falls into the trap of data, numbers, statistics, and charts? Because here's the truth: most of these disciplines aren't quantifiable, scientific, or precise. They are messy and complicated. And when you try to straighten out the tangle, you may find that you lose far more than you gain.

It's one of the things that irked me about political science and that irks me about psychology—the reliance, insistence, even, on increasingly fancy statistics and data sets to prove any given point, whether it lends itself to that kind of proof or not."

(Maria Konnikova, 10 August 2012, Scientific American)

Bruce McLean, "Pose Work for Plinths 3", 1971, 12 photographs, black and white, on paper on board, 75 x 68 cm (Tate).

1

TAGS

appropriately complex representation • attempts to quantify the qualitative • Carol Tavris • easy empiricism • erroneous • error in reasoning • fallacious arguments • faulty reasoning • generalisable simplicity • hard science • Herbert Gintis • humanities • ignorance • imperative of generalisable simplicityimperative of proof • irreducible elements • Isaac Asimov • Italo Calvino • Jerome Kagan • Maria Konnikova • metricisation • nonsense • over-reliance on empirical methods • over-reliance on science • overly reductive • perils of reductionism • post hoc explanations • post hoc hypotheses • pseudoscience • psychohistorical trends • psychology • qualitative phenomena • quantifiable certainty • quantification • quantitative analysis • reduced to scientific explanation • reductionist perspective • Richard Polt • Scientific American (magazine) • scientific-seeming approaches • scientification • scientism • unquantifiable • unsound judgement

CONTRIBUTOR

Simon Perkins
15 DECEMBER 2015

The place and value of research modelled on generalisable simplicity

"The health professional education community is struggling with a number of issues regarding the place and value of research in the field, including: the role of theory-building versus applied research; the relative value of generalisable versus contextually rich, localised solutions, and the relative value of local versus multi-institutional research. In part, these debates are limited by the fact that the health professional education community has become deeply entrenched in the notion of the physical sciences as presenting a model for 'ideal' research. The resulting emphasis on an 'imperative of proof' in our dominant research approaches has translated poorly to the domain of education, with a resulting denigration of the domain as 'soft' and 'unscientific' and a devaluing of knowledge acquired to date. Similarly, our adoption of the physical sciences' 'imperative of generalisable simplicity' has created difficulties for our ability to represent well the complexity of the social interactions that shape education and learning at a local level."

(Glenn Regehr, 2010)

Regehr, G. (2010). "It’s NOT rocket science: rethinking our metaphors for research in health professions education". Medical Education, 44(1), 31-39. doi: 10.1111/j.1365-2923.2009.03418.x

1

TAGS

applied researchappropriately complex representationclinical situationscomplex phenomenacomplexity • contextually rich solutions • devaluing of knowledge • dominant research approaches • education • education and learning • epistemological positionsgeneralisabilitygeneralisable simplicity • generalisable solutions • generalised models • Glenn Regehr • health education • health professional • health professional education • ideal research • imperative of generalisable simplicityimperative of proof • local research • localised solutions • multi-institutional research • myth of neutralityperils of reductionismphysical sciences • place of research • questioning assumptions • research in the field • research modelresearch-practice gulfrich descriptions • role of theory • role of theory-building • social interactions • soft science • theory building • unscientific practices • value of research

CONTRIBUTOR

Simon Perkins
26 OCTOBER 2014

Donald Norman: The Research-Practice Gulf

"There is a great gulf between the research community and practice. Moreover, there is often a great gull between what designers do and what industry needs. We believe we know how to do design, but this belief is based more on faith than on data, and this belief reinforces the gulf between the research community and practice.

I find that the things we take most for granted are seldom examined or questioned. As a result, it is often our most fundamental beliefs that are apt to be wrong.

In this talk, deliberately intended to be controversial. I examine some of our most cherished beliefs. Examples: design research helps create breakthrough products; complexity is bad and simplicity good; there is a natural chain from research to product."

1
2

TAGS

2010abstract models • applied social science • appropriately complex representationbreakthrough innovation • breakthrough products • call to actionChicagocomplexitydesign and innovationdesign communitydesign conferencedesign practicedesign research • design research conference • designer-centred designdisruptive innovationdogmaDonald Normanethnographic design approach • existing product categories • failure of design research • fundamental beliefs • generalised modelsHCDhuman-centred designideation • IIT Institute of Design (ID) • Illinois Institute of Technology (IIT) • incremental innovationinnovation process • innovative breakthroughs • keynote address • product developmentradical innovationrapid prototypingreal-world designreal-world projectsresearch communityresearch-practice gulf • results-driven • simplicitytesting perpetuates mediocrity • translational engineering • translational sciencewhat designers do • what industry needs

CONTRIBUTOR

Simon Perkins
18 APRIL 2014

Design conceptualisation through reverse engineering abstraction

"2.1 Abstraction Levels: An abstraction for a software artifact is a succinct description that suppresses the details that are unimportant to software developer and emphasizes the information that is important. For example, the abstraction provided by high level programming language allows a programmer to construct the algorithms without having to worry about the details of hardware register allocation. Software typically consists of several layers of abstraction built on top of raw hardware; the lowest–level software abstraction is object code, or machine code. Implementation is a common terminology for the lowest level of detail in an abstraction. When abstraction is applied to computer programming, program behavior is emphasized and implementation details are suppressed. The knowledge of a software product at various levels of abstraction undoubtedly underlies operations regarding the maintenance and reuses the existing software components. It is, therefore natural that there is a steadying growing interest in reverse engineering, as a capable of extracting information and documents from a software product to present in higher levels of abstraction than that of code. The abstraction as the process of ignoring certain details in order to simplify the problem and so facilitates the specification, design and implementation of a system to proceed in step–wise fashion. In the context of software maintenance [3], four levels of reverse engineering abstraction are defined: implementation abstraction, structural abstraction, functional abstraction and domain abstraction.

Implementation abstraction is a lowest level of abstraction and at this level the abstraction of the knowledge of the language in which the system is written, the syntax and semantics of language and the hierarchy of system components (program or module tree) rather then data structures and algorithms is abstracted. Structural abstraction level is a further abstraction of system components (program or modules) to extract the program structures, how the components are related and control to each other. Functional abstraction level is a higher abstraction level, it usually achieve by further abstraction of components or sub–components (programs or modules or class) to reveal the relations and logic, which perform certain tasks. Domain Abstraction further abstracts the functions by replacing its algorithmic nature with concepts and specific to the application domain."

(Nadim Asif, 2003)

Nadim Asif (2003). "Reverse Engineering Methodology to Recover the Design Artifacts: A Case Study". International Conference on Software Engineering Research and Practice, SERP '03 Las Vegas, Nevada, USA. Volume 2.

TAGS

2003abstract representation • abstraction layers • abstractions for problem solving • application domain • appropriately complex representation • conceptual hierarchy • conceptual organisation • conceptualisationdesign abstractiondesign conceptualisationdesign methodologydesign modeldesign problem • domain abstraction • functional abstractionhigh-level design • implementation abstraction • layers of abstraction • problem abstractionproblem-solvingrequirements engineeringreverse engineeringreverse engineering abstraction • Reverse Engineering Abstraction Methodology (REAM) • software abstraction • software artefact • software designsoftware engineeringsoftware modellingstructural abstraction • system components • system processes • systems theory

CONTRIBUTOR

Simon Perkins
29 OCTOBER 2013

Creating a Technical Specification

"A technical specification is a document that defines a set of requirements that a product or assembly must meet or exceed. A product or assembly that does not meet all of the specifically expressed requirements does not meet the specification, and often is referred to as being out of specification or 'out of spec.' Specifications are used when a contract for technical products or services is issued. The technical specification defines the requirements to fulfill the contract."

(WikiHow)

1
2

TAGS

abbreviations • appropriately complex representation • business document • clarity of thought • closed specification • contractual requirements • description of realitydesign projects • detailed specification • direct sentences • explicit definitionsexplicit meaningexplicit objectives • general requirements • industry terms • jargon • open specification • operational criteriaoperational definitions • out of spec • out of specification • performance requirements • precision • product or assembly • product requirements • professional communication practices • project specification • quantification of variablesquantified measurement • required performances • requirements gatheringrequirements process • set of requirements • software engineeringspecification • technical product • technical requirements • technical specification • TLA

CONTRIBUTOR

Simon Perkins
Sign-In

Sign-In to Folksonomy

Can't access your account?

New to Folksonomy?

Sign-Up or learn more.