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