In many formal methods, the state is assumed to be hidden, and the user’s view of the state is represented by observer actions that produce outputs but don’t update the state. It’s easier to just assume that the state is by default visible to the user, and to describe how and when the user can view the state as part of the user interface mapping.
Viewing an app in terms of its state and actions lets you think about its behavior concretely, but without having to consider the details of the user interface. And when you come to design the UI, you can ask yourself how to map the states and actions to UI views and widgets.
Mercury is…
(1.) Fluid
Instead of asking people to modify their thoughts and actions around the arbitrary sandboxes of Apps, Mercury responds fluidly to the intentions of its user, alleviating the risk of interstitial friction that all multi-tool workflows carry.
(2.) Focused
The clutter we take for granted in today’s operating systems can be overwhelming, especially for folks sensitive to stimulation. Mercury is respectful of limited bandwidths and attention spans, and rejects the idea of “notification driven engagement.” Information will not be pushed to the user unless they intentionally ask for it. Mercury’s intention-as-context architecture vaccinates the user against the unintentional consumption of information.
(3.) Familiar
Mercury introduces new ideas and metaphors through familiar interaction patterns on an existing device: Mercury is designed for multi-touch tablets with keyboard support — a category often overlooked as awkward hybrids straddling two worlds. Mercury...
does it work in B&W?
does ir work in e-ink?
