diff --git a/src/gui/model/tangible.hpp b/src/gui/model/tangible.hpp
index 984a3ebb8..eaffbb641 100644
--- a/src/gui/model/tangible.hpp
+++ b/src/gui/model/tangible.hpp
@@ -59,7 +59,7 @@
  ** like a common styling. These are addressed the conventional way, through a common \ref WindowManager.
  ** The following discussion focuses on the aspects of integration with the core.
  ** 
- ** For one reason ore another, any element in the UI can appear and go away.
+ ** For one reason or another, any element in the UI can appear and go away.
  ** This lifecycle behaviour corresponds to attachment and deregistration at the UI-Bus
  ** 
  ** In regular, operative state, an interface element may initiate _actions_, which translate
diff --git a/tests/gui/abstract-tangible-test.cpp b/tests/gui/abstract-tangible-test.cpp
index 20d6b24c7..d71d2e78c 100644
--- a/tests/gui/abstract-tangible-test.cpp
+++ b/tests/gui/abstract-tangible-test.cpp
@@ -367,6 +367,14 @@ namespace test {
       markState ()
         {
           UNIMPLEMENTED ("mark interface state");
+          // verify both directions of state marking
+          // expand and collapse the mock
+          // and verify that the corresponding state marks appear at the bus
+          // then replay those state marks
+          // at least the doMark should be invoked
+          // TODO maybe we'll even provide a default implementation for expand/collapse
+          // which then means that, by replaying the mentioned state marks, the
+          // doExpand() or doCollapse should be re-invoked
           
           TODO ("be sure also to cover signal diagnostics here");
         }
@@ -376,6 +384,8 @@ namespace test {
       notify ()
         {
           UNIMPLEMENTED ("receive various kinds of notifications");
+          // send msg, error and flash messages via Bus to the element
+          // verify the doMsg, doErr or doFlash get invoked
         }