I like the mashup as a user conceptual model. A broad definition of a mashup would be to take two or more unlikely objects or concepts and mashing them together to find if they make something meaningful.
Examples: For internet users, an example of an interesting mashup as user experience is maybe Pageflakes at http://www.pageflakes.com This website mashes together tons of sites you might like into one global view. It’s pretty handy.
For furniture, I’ve seens some really fresh mashups such as the Giant Sketch athttp://www.mattermatters.com/search.asp?Mode=Product&ProductID=176 The concept is a massive sketchbook mashed up with a table.
Not to bust your chops too much with semantics, but user centered design would say that ANY conceptual model a user has is a good one simply because they have it. A “conceptual model” (or mental model) generally refers to the way a user thinks a system works; for example, with a lock and key, a conceptual model would be “I put my key in the lock, and there’s an inverted shape of my key, and if they match up, the door opens”. That’s totally wrong, but it allows people to get through their days without understanding pins and wedges and mechanisms and whatnot.
I’m not sure a mashup has anything to do with users; it’s a rather strange technologically-driven phenomenon that, in my experience, most users don’t understand or care about…
Norman (1983) distinguishes between mental models and conceptual models: “Conceptual models are devised as tools for the understanding or teaching of physical systems. Mental models are what people really have in their heads and what guides their use of things. In other words, the designer designs a conceptual model into the system in order for it to appear graspable and coherent to the user. If he/she manages to get the conceptual model right, the correct mental model (in the mind of the user) will follow.”
Then again, perhaps the inventor of the keylock had a conceptual model in mind all along…
According to Cooper, you would be looking for good examples of the Manifest Model:
We tend to form mental models that are simpler than reality, so creating manifest models that are simpler than the actual implementation model can help the user achieve a better understanding.
And in that respect, keys would work just fine. Another example would be the breaking system on a car; it manifests itself as a friction system (ie, I jam the break down and apply friction directly to the wheels) which works just fine when someone needs to stop the car pretty quickly. Of course, that’s not at all how the car works, but that’s the point
Most microwave oven interfaces would be pretty horrendous examples, as the UI usually maps directly to the underlying circuitboard…
Back in the day, they called microwave’s “radar ranges.” Today it’s popular to say “nuke” rather than “microwave.” As in, “I’m going to nuke a couple of dogs for lunch.” It’s a good conceptual model to explain the mystery of what’s happening to your food.
Agreed about the sad state of their UI design–it’s very system-oriented. Bring the knobs back!
One of the first things that could be mentioned is that the starting model may have changed a bit.
If you look at can design, at first there were a ton of designs for opening devices. (Ostensibly, can openers)
Years later the pull tab with a ring that fully removed the closed area was the best idea. With a quite large ring to put your finger through.
Today, nobody expects me to fit my fat finger into the tiny ring of the pull tab, but I know how to open the can. The pull tab now does not remove from the device, and is impossible to insert my finger into the tab. Yet it is still shaped with a small ring location.
Not to split the can from the opening device, but it seems that the environment is the same when I need to open a can. however I now easily recognize that a pull tab means open.
Or to further the idea. On most 7-1/4 diameter saws.
I wonder if Skill was the first company to have a blade depth adjustment handle (usually near the Grip of the handle) that cammed a nut tight for blade height.
Today I believe 100% of all companies adjust blade height that way. It honestly sucks because the carpenter strips the bolt, yet the desigher must not know that that is a poor method for blade adjustment.
Point is-- today there has not been a DIFFERENT way introduced to adjust blade height in 25 years. I think the conceptual model for blade height adjustment is stagnant for that design.
CG, because you brought up Lotus, I constantly still throw an alt-TAB in another program that does not have that function as I would expect.
I think there are examples of change in the conceptual model as well as stagnancy in the conceptual model.