Appreciate this constructive signal.
I know some – even some present in thread – are likely more sceptical as to (direct) use of “AI” for such things.
I can relate to using such tools, if done with a view helpful in such a complex process as UI/UX-architecturing (– which for a reason is a science, profession and trade).
So, curious how this might be taken up as part of the process.
Then,some notes of caution as to the expectations re. mockups from user side, esp. in such early stage discussion which haven´t even progressed to the fundamental stage of problem identification/definition. Not to talk of team processes, and fit/adaptation to these in such complex processes as UI-revision (which IMU is not even on the table here).
Still curious to see whether this solicits constructive engagement…
PS – after studying your mockups. I think this is already right in the direction discussed. Not sure people/team share the take – but it certainly reflects some central things which has been said/raised here. – One thing not in there, IMU: if one treats all annotation-(aside-)note aspects as truly part of one functional complex, there is one thing that additionally belongs in such UI-musing: the scenario where one finds the aside-note independently of the “parent”-document. – So, in your version this should/could also go into the Document Inspector as well as in the File List. (To give an esspecially interesting scenario/context: annotated images/media! Here, it is very likely to first find the annotation (not the parent) bec DT-search is obviously text-focussed. Then, especially in this context (images/media), such additional textual aside-annotations make a lot of sense, bec it (indirectly) feeds the document into the DT-core processes (like “see also”, concordance etc.)