Feedback on ER-301 Wiki-based Documentation

First thing I find that’s missing is that you write of the Local, Global, Input chains but don’t explain them.

Edit: That was the only thing missing. Love the detail.

1 Like

looks great!

I really like the examples and the accompanying diagrams.

What was your thoughts behind the “sink” naming convention? You’ll have to take that out of the random name generator :wink:

The only potential conflict is that it audibly sounds exactly like “sync”. So renaming the sink for my oscillator sync could get confusing?

2 Likes

Thanks for all the hard work on this. It is great seeing the docs come together!!

3 Likes

Applause! :clap:

2 Likes

Super nice and clear !

1 Like

Loving the wiki updates, almost feels like I am getting new functions and stuff as getting a better understanding (or at least a more confident one) inspires new ideas.

1 Like

Yes!
So exciting to see the documentation coming along!
And I agree it feels like a “new” module emerges with the deeper understanding and clarity!

Esthetically I prefer the B&W illustrations that use the screen shots, with red additions. More so than the pastel color diagrams… The all color diagrams (like this: File:Signal-flow-overview.png - O|D Wiki) feel so distant esthetically from the rest, and also somehow “foreign” esthetically to the visual feel of the module and the module displays. If the colors are needed for clarity, I would still use the B&W screen shots, and use additional color lines (in addition to red) to highlight the relevant aspects of the image. (Just my bit of unsolicited feedback :slight_smile: )

1 Like

I am also a bit confused about the “sink”…

The colours do provide that added level of visual clarity to differentiate between the Unit, unit control etc… The only thing it makes me want is a coloured ER301 screen :smiley:

2 Likes

I agree. I was suggesting that the additional colors can be used to make those differences visible, but using the colors the same red is used in all the other illustrations. Perhaps for the sake of cohesion?

I just don’t see the need to redraw the actual interface, like in this image:

in order to convey information that can just as easily be conveyed by using the screen shots with color coded annotations.

Additional benefit I see in using the actual interface images is that it reinforces the visuals in user memory: what you see in documentation is exactly what you see on the module.

ALSO:
I was one of the geeks who was totally excited about the first photos of er-301 including the Edward Tufte books on information design. I see a great care in the way interface is being designed on the module, and so I am, perhaps unfairly so, applying the Tufte standards to the visual display of information in the documentation documents as well…

3 Likes

I don’t really care that much, just happy the documentation is starting to appear, but as a very minor gripe, I do agree!

I kinda grumbled a little bit about the screenshots too…

…but hey, the last thing I would want to do is to be discouraging in any way - everything is full of awesomeness… and then some!

I do not want this to be considered a complaint in any way :blush:

Not a complaint at all!

Just feedback, “thoughts, critiques, confusions” (as per the thread title and the original post).

I LOVE the fact that documentation is emerging!

1 Like

I spent a little time looking up the sink terminology and the closest I could find is this:

It’s not uncommon in computer science to refer to an output as a “sink”. Although typically it’s in the context of writing to some persistent store.

The source/sink terminology is borrowed from network and graph theory.

3 Likes

Read the better part of this article on Flow Network and dig that you are forging an aesthetic path forward by utilizing terminology as you see and feel how it relates to your creation. The mutability of language and evolution of technology.

1 Like

@laborcamp

Thank you for the well-written critique! To be honest, your thoughts on the colored diagrams shadow some of my feelings as I was drawing them. However, there were 2 stronger (for me) issues that pushed me to the current result:

  • There is no way to show a larger bird’s eye view of how multiple chains may interact using only real screenshots. The larger chain structure cannot exist in the 2D plane without seriously warping spatial relationships. So I thought to myself, I will go to the other extreme and use a style and color palette that implies that the diagram is a “theoretical” representation so that users do not mistake it as an actual snapshot of the visuals that the user is navigating on the ER-301.
  • So that I can focus on the ideas in the “Patching Language” section, as separate from the UI implementation, I needed an abstract & simplified representation devoid of all the trappings required by an actual interface. Blocks of color are my usual go-to solution for such “idea images”.

Do you have anything to add in the light of these two points?

Following your train of thought I can see why/how you arrived at the decision.

But I am curious about the “impossibility of showing the larger chain system in 2-d space”. The examples I saw seemed manageable, so I am imagining a crazy complexity you might be planning, or for seeing in the future. And it sounds like a fun visual challenge!

My other thought was regarding the new “simplified” visual representation used to show the patching structures being intentionally NOT like the UI. If that is the objective, then I wonder if it ought to go even further in simplifying or abstracting the chains and connections…?

And again, just want to reiterate that my comments come from the best place possible, and are not intended to derail or criticize, but rather simply offer an “outside” yet sympathetic pair of eyes for feedback in the process. I love a good diagram, and as a visual artist I may be guilty of sometimes overthinking “options” at every step of the process. I recently helped Brian at monome with diagrams for a ansible documentation (Redirecting…) and found the process quite satisfying. It’s always an exercise in balancing the amount of information offered, ease of understanding and elegance of form.

3 Likes

Yes - this is a great idea!

…and I love your diagrams on the Ansible site - they are very good indeed!! :+1:

1 Like

“Just as the human memory is not a passive recorder but a tool in the construction of the self, so history has never been a simple record of the past, but a means of shaping peoples.” --Arthur C. Clarke

http://wiki.orthogonaldevices.com/index.php/ER-301/Persistence

2 Likes