No actual waykit to problematize combine the overriding theory fixes with these waykit fixes ... - - - - - - - - - overriding waykit fixes - - - - - - - - - - - - - - - - - - - - - -! want cooperation on common means at the intersection of rival ways - where a given intermediate means (step in way) happens to be substantially shared - by rival ends - by rival groups of actors - want to facilitate cooperation on that means ( despite the rivalry elsewhere - why - consensus is far more elusive than we typically foresee and allow for - it will be scarce, shifting and short lived even at the way extremities - ultimate ends always being frayed to the smallest detail at the leaves - actor groups being somewhat frayed - but at times completely dissolving or shifting - and reforming - as the larger enactive power structure reforms - crucial to make the most of consensus where and when it happens -! want structural skeleton first ( notebook 2017.6.18 - to be decorated only later by functional clothes - else the initial design will overtask me -! want hands on = small tools for desktop ( controls, views, etc. - loosely integrated components - developed in parallel with the existing Android UI - which is more tightly integrated and spatially constrained - ∴ harder to shape - easy to shape -! want immediate personal utility - in my own work on the desktop -? what's useful to me | context = explore this "hands on" with the proposed desktop tools + starting here, where I feel the greatest need | selected waynodes + intermediate ellipsing as needed - selecting and showing sufficient waynodes to orient the viewer ( notebook 2017.7.8 - text-form view ( notebook 2017.7.11 - basically a text form - because it'll be more immediate than a graphical one - a better, less problematic fit with the underlying HTML of the wayrepo | intermediate ellipsing - way terminii as main context and framing structure ( notebook 2017.1.27 - ultimate end (left) and ultimate means (right) - as opposed to full waypath - - - - - - - - - overriding waykit fixes (end) - - - - - - - - - - - - - - - - - - ... so entwined, theory and practice will support each other as they grow Code the Android UI far enough to range the ways of the local wayrepo -! screens are going to be too crowded |= defer to results of desktop design | restrict to a single mode of movement|navigation at any one time - way | forest - use this restriction to gain screen space and reduce clutter = try to upgrade to latest Android image - testing for clearance of SAF bug ( https://code.google.com/p/android/issues/detail?id=210861 - coding the minimum in order to test a climb = enable up climber in ForestV - when - peers viewer shows actor - actor has voters = request voters of peer that becomes actor = show uncertain state of voters - by imaging as empty outline (bright) - thence to filled icon - either enabled (bright) or disabled (dim) - asserting !isRemotelyUsable where the current implementation might not allow for delay - minimal allowance would be addition of information to indicate temporary|uncertain|pending state at point of effect - e.g. not knowing, pending enqueuePeersRequest for voters, whether up climber can actually climb = define real positions near root = ensure that node handles share same minimal width - for stability of forest view - expandable within limits = ensure that animation works as expected ' setLayoutTransition( new /*default*/LayoutTransition() ); // animate layout changes ( http://developer.android.com/guide/topics/graphics/prop-animation.html#layout - may need to customize using LayoutTransition.setAnimator = repopulate ForestV on forester movement - comparing candidate path vs. model ( notebook 2015.12.26 Allow the initial problems of the waykit to surface in this form