Skip to content
jdittrich edited this page Jan 2, 2020 · 2 revisions

Pen and paper works very quickly, but as soon as you need to change something, you need to redo a lot of things. This can stifle creativity and quick explorations.

Existing implementations:

Notes

Usecases are, e.g.:

  • rearrange the order of elements in a list
    rearrange list items
  • Put a sidebar from the left side to the right (which would leave an empty space and overlap elements at the new position)
    rearrange sidebar
  • remove a header image (which would leave an empty space)
    deleting header image
  • resize header image
    resize vertically
  • resize sidebar
    resize horizontally

Here the problem would be to determine for smaller changes if the element should be just resized into whitespace or if elements should actually maintain distance and be pushed. Note that the container needs to grow/shrink, too (not needed for position changes/rearrangements)

reflows

  • Assume that a reflow is triggered as soon as elements do overlap (needs refinement!)
  • Assume that elements have a direction to go in their container, e.g. "upper left corner" (or more generally: start of reading position)

Groupings

The notion of things-in-a-container is important for adjusting positions. Such containers can be

  • explicit (in a DOM like hierarchy)
  • based on selection (the elements which are currently selection are in an "implicit" container)

If the elements which movement triggers the reflow take up the whole space in their container either vertically or horizontally, the direction for the reflow is clear.

For elements that do not take up the whole space in one direction it could be assumed that they fill up empty space in the container, thus implicitly determining direction:
determine direction via implicit expansion

There are some common structures which assume nested flows in different directions, e.g. first vertically, but for some vertical elements also horizontally:

image

Here, ideally it should be possible…

  • to swap the avatar image with the new-Repository Button (by dragging the avatar on the button, which should trigger swap, cause non of them is a container)
  • to reorder any of the full-width elements by dragging them – and the entries that are vertically split (repositories/new and avatar/username) are part of this.
  • Now a ambiguous one: drag the avatar| avatar/username in front of the search field ).
    Now two things could happen:
    • avatar-image moves: The username then would expand to full size and the search-input would share the horizontal space with the avatar image. (which is semantically nonsense, but just for the illustration)
    • The whole row of avatar/username moves to a new place

I guess the latter (whole row move) makes more sense here, but it our mileage may vary.

We probably would need some TeX like algorithm giving us a score of what action is better. Where to place something could be solved with hit zones on objects: Putting it in the center=split against main direction, putting it in the top or bottom area of an element assumes the new thing goes between it and the next element:
image

However, this does not help to determine what should be dragged in the first place! We could get handles on objects:
image Or we go with the good old "double-click gets on one layer deeper" mechanic. Not soooo great, cause not indicated by UI and introduces a stack-state of "now I am one/n layer into the stack".

Clone this wiki locally