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.
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.
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
The only potential conflict is that it audibly sounds exactly like “sync”. So renaming the sink for my oscillator sync could get confusing?
Thanks for all the hard work on this. It is great seeing the docs come together!!
Applause!
Super nice and clear !
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.
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 )
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
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…
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
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!
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.
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.
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:
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.
Yes - this is a great idea!
…and I love your diagrams on the Ansible site - they are very good indeed!!
“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