#12

I’m a total bystander in this conversation—don’t have a grid, probably won’t get one for years although they’re beautiful and inspiring from this remove. But, I did also download a bunch of Max patches for grids—with the intention of figuring out how I could replace the grid interaction with hacky BeatStep Pro control—and have been frustrated by how I can see some aspects of what is going on, but in general would really have to commune with the source to find out what is going on, especially without being directly able to just press buttons.

As I sit here, I don’t really think that this is a complaint about the user interface, but rather how much of the knowledge of how these Old Things tick has been lost as the community and creators move on to New Things. And like, on some level, it’s fine, just a shame.

1 Like
#13

I sincerely hope that the New Thing, due to use of many mature, text-based, open-source technologies, will be much less prone to backwards compatibility issues than the Old Things were. This should mean that the wisdom we start accumulating now stands a chance of surviving for decades in a completely usable form.

Hopefully that also means that some of the people responsible for that wisdom will also stick around!

2 Likes
#14

From this perspective moving to Supercollider/linux is certainly a great move!
Still, it rests on the shoulders of everybody who will contribute to document – at least to some extend – their creations, and maintain that documentation.

2 Likes
#15

that would be brilliant, yes!

off topic, but it’s funny how often I feel “green” lately. finally able to participate meaningfully in Big Projects and Conversations… only to realize how much there really is to catch up to in terms of skills and experience to really start to move things. I guess that’s probably just endemic to being in one’s 20s :sweat_smile:

1 Like
#16

You’ll be gray and brown like the rest of us soon enough. Enjoy being green while you can!

1 Like
#17

this is a side note, but it would be great if we had some shared repository of assets to help make visual interaction documentation easier for people. I know that @ether basically reverse engineered existing monome documentation to create a guide to @scanner_darkly’s ansible earthsea port, but it seems like we could make that easier. now with norns on the way, there’ll be another surface to document as well if we want to make interactions clear.

I guess a bunch of stuff could also live in the comment section for lua, but I like the idea of people being able to relatively quickly and easily put together a page or two on how to interact with their norns creations.

#18

As I was describing interaction patterns above, I was imagining how I’d set up a Sketch library to make documenting those patterns easier.

This is sounding more and more like an actual project I’m actually going to pursue…

6 Likes
#19

Yes, now you have to :smiley:

This said, the way things have developed on the Teletype are certainly a good “best practice” example in my opinion.

1 Like
#20

Please do. I spent some time a few months ago trying to think through some arc functionality and wound up recreating the arc documentation visuals in keynote so I could play around with them, but it would be great to have a set of images anyone could just start with.

1 Like
#21

OK. Fair warning: my drawing tool is Sketch, and that’s how I plan to do this.
https://www.sketchapp.com/

Many many reasons why this tool has become so popular for interaction design.

2 Likes
#22

Sketch seems good. If people wanted to take the assets you produce to make their own documentation, is there a free app that you would recommend that would suffice?

#23

Inkscape is free.

I’ll make SVG exports from my Sketch files that will be usable in Inkscape. You’ll miss quite a few niceties that make things more convenient, but it’ll work.

1 Like
#24

i think defining grid (and arc) interface conventions is a useful exercise, with some exceptions, depending on the goals.

i doubt that it’s feasible to try and follow these conventions for all apps. simply because the restrictions imposed by grid itself tend to make UI much more app specific. a lot of times unique controls are needed both to fit it into 128 LEDs/buttons and to make it intuitive (as a side note, designing a friendly user interface can take more time and planning than writing the actual code).

so, designing with some preselected set of controls is doable but will be probably limiting in practical terms. it might sound contradictory considering the many very different things that were already created with a limited set of grid ops, but grid ops were built with a very specific goal in mind, to allow creating flexible enough UI within limited scripting space that teletype provides. as such they have to pack as much functionality as possible in as few ops as possible. so, say, the fader control is both limited (it works in a set way and can’t be styled much) and flexible (to be efficient for both coarse and fine adjustments). so the approach to designing grid ops was: try to limit the number of controls and their properties, but provide some other ways to style UI (like drawing on top of other controls).

if we talk about norns specifically though, i think it makes total sense to have a library of typical controls. this will help with building apps quickly, especially since it’ll be more natural to define a grid “button” and work with that, instead of writing code for processing grid presses / maintaining button state / rendering. having a predefined set of controls will also help with usability aspect, but again, i think for simple apps that’s fine but for more complex apps they will likely have a very app specific non traditional UI.

as several people mentioned, this really comes down to having documentation. so if there is some way that that could be simplified too i’m all for it! (when documenting orca i did it in power point because it’s surprisingly easy to use for diagrams, but still it’s a very manual process, i’d love some editor that would simplify that).

and having a catalog of different UI elements/approaches for grid would be a cool thing to get ideas for norns/tt/max etc grid apps!

6 Likes
#25

Agree with all that.

One thing that is nice about this process is that it will over time gradually move from the abstract (“what do we mean by ‘a control’?”) to the concrete, as tangible assets start to accumulate. We will spend less time verbally hand waving and more time writing docs! :wink:

2 Likes
#26

sketch%202018-05-08%2021-42-30
monome-grid.sketch 2018-05-08 21-42-30.jpg2242×2358 801 KB

Work is in progress. I’d like to do some real work with it before I distribute it. Does anybody have any grid apps that need some documentation? @tehn? @scanner_darkly? Beuhler? Beuhler?

I started to make “rows” but quickly found that any larger abstractions were just cumbersome to work with in Sketch vs. just changing the brightness of individual buttons.

9 Likes
#27

that looks great! wish i had some grid apps that required documenting :slight_smile: but nothing at the moment. might be cool to try it for some of the teletype grid scenes, once i have a chance to make them more sharing-friendly.

i just had a sad realization moment, sketch is mac only, which means i won’t be able to use it unfortunately. is it something that can be ported to some windows app?

#28

Like I said previously, it will export in a variety of formats. But there is no app that works as nicely as Sketch that I’ve found.

SVG in Inkscape is probably the best free approach.

1 Like
#29

This is probably a bit left field for many, and a little offtopic. But the Haskell Diagrams library is great for making diagrams for those who understand Haskell (this statement is somewhat redundant).

Examples: https://diagrams.github.io/gallery.html

Haskell is also really good for making embedded DSLs, an enterprising individual could create one for describing grid apps which could spit out pretty pictures too. I expect there are similar solutions in other languages.

The big advantage of something like this from a documentation point of view (though maybe not a design PoV), is that the script to generate the diagrams can be stored in you Git repo alongside all your other code.

2 Likes
#30

SVG files are text files, and therefore also possible to store in Git.

That being said, we regularly use Git for binaries at work, and I’ve never seen it cause any problems.

#31

It’s more the script part of it I suppose (for me anyway). It would make it very quick to update documentation alongside code changes.