Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

There is always the discussion whether the UI should "hide the implementation details" (make the internal model, which differs from the conceptual model, invisible -- resulting in hard-to-understand behavior) or "make the implementation details visible" (change the conceptual model to be equal to the implementation model, and force the user to adapt to that).

But the one option that is rarely used but yields the (IMHO) best results is: design the conceptual model, then build/change the implementation model to be equal to it.

One example for this strategy that is forever stuck in my head is macOS application folders. The conceptual model is that an application can be moved around like a file, and applications be organized in folders like files. But you also want to run an application by double-clicking it. Instead of what Windows (and then Linux) did with links, menus, installing applications and centrally registering them etc., the implementation was changed to be like the conceptual model. A whole class of errors from inconsistencies just vanished.



I'd argue the implementation detail is still hidden. You don't know if Applications use FUSE or are WASM containers or docker images or what not.

Interface is a translator between what user understands ("I press button, channel changes") and implementation detail ("rubber dome changing resistivity, ...causing IR signal to be sent", ...).


Excellent point and example!

Joel Spolsky described these as "leaky abstractions". If the implementation does not quite match the conceptual models, then the implementation "leaks out" to the user. The user is confused because the UI does not match the conceptual model in their head.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: