Norns: updates

norns

#102

cross-post from Norns: ecosystem but we’re trying to figure out a better way to “add projects” without doing a full update, or when something comes out mid-update cycle.

at a certain point there are going to be tons of norns scripts, and i think the user will prefer to pick and choose and collection rather than be confronted with a huge list of always-included scripts.


#103

That day may arrive - but if the scripts themselves take up only negligible space, perhaps the following would be a better option:

  1. All QA-approved scripts in dust are loaded to the user’s Norns on update, but…
  2. Users can set “favorites” for the top-level script menu selected from the larger list so they’re not confronted with everything en masse.

This way, as I see something magical pop up that I’ve never thought of using before, all I have to do is try it out, then if I like it, I can “promote” it to a favorite.

For your consideration.


#104

I like the idea of having access to the whole community from the norns UI.

It might be great to have a monome curated collection (like we have for the grid apps). That could end up giving 4 places find scripts:

  • user created scripts
  • favourites
  • monome curated collection
  • community

But that would imply a serious amount of design work to get a natural UI to navigate through these.


#105

having just done a pull on dust to pick up the latest foulplay - it occurs to me there is another potential requirement here:

letting the user know something has changed - you may have looked at something but an update to a script could make it more interesting to you. Could just be as simple as a dot next to the name (although my iPad does that and I just ignore it), could be as complex as a “change list” that displays a quick note included from every changed script in a single scrollable list*. Dunno - it isn’t a “must have” but I suspect from a use-ability point of view would be very nice indeed

  • you’d have a recent-.txt with every script or something - the author would be responsible for the content

#106

This could be included as part of git support features in maiden, potentially. I need to wander over to github and find out what issues are already in progress for maiden…


#107

I was more thinking for the kind of user that will never edit scripts

We had a feature in our product at work that used git change stuff to give customer information for a while - it was horrible. this kind of thing needs to be authored/created specifically


#108

There’s no reason it needs to be horrible.


#109

the issue was - the information that developers needed to put in for their own needs/other developers needs etc was very different from what the average end user wanted to know. Also distinguishing which updates needed including. Essentially - it either broke it for the developers OR end users - impossible to keep both happy.

You and I are happy reading git change logs -we filter the noise because we know what it means give or take. I’m really thinking of the kind of user that will never edit a script on their own but is a happy user of Norns


#110

So, you don’t want “script changed”. You want “script has had several changes and is now ready for release”. So, that means the “new” dot is reacting to releases/tags rather than mere commits.

Yes, it needs to be designed, but there’s value in existing git infrastructure that can be made useful for both developers and non-developers.


#111

That being said, the notion of keeping master non-broken sort of obviates the need for a notion of “release” around a script. It seems that breaking changes will never get merged to dust, so if true, that would mean any merged PR to dust could be thought of as a “release”.

The mechanics of all this would certainly require discussion prior to implementation.


#112

I’m not explaining myself very well.

I guess what I’d like to see is something like

"Foulplay - new phase feature, several bug fixes. " kind of thing (just made the bug fixes part up )

I know that there doesn’t want to be “releases” but scripts will change over time and it would be good to inform people of headline new stuff

Again - I’m thinking about usability for more casual non coding users. Mentioning it now because it’s the sort of thing that is better thought about early rather than being bolted on.

And just sharing experiences of trying to use git like this (it seemed like a reasonable idea when it was first mooted which is why I let it be built but that feature is no longer there for good reason)

also to try and be clearer - I’m not talking about “releases” even of the scripts - I’m talking about - the script author has added some cool stuff and wants to let potential users know about it if they are interested


#113

What probably isn’t very clear is that I am imagining this to be a GUI driven experience within maiden. It doesn’t necessarily have to be obvious that git is underneath, from a user perspective. I think what you’re asking for is in line with how I’m imagining between-norns-release script updating via maiden-enhanced git (which is just an idea so far). Ideally part of the discussion leading up to implementation should include mockups for community feedback.


#114

yeah cool - given I had this exact same conversation at work and then pulled the feature - I thought I’d share but it might turn out differently here…


#115

if this get’s done i’d like to opt out
i like the monome team but i don’t want them curating my collection of scripts

one aspect i like about the current system is that all user folders (and scripts) exist on equal footing


#116

My understanding of the word “curate” in this case is less of a “choose what gets presented” than “ensure that what is presented has passed QA and actually works”. Put another way, there can be many curators (in effect, many collections of “favorites”) but all of them should function, or at least their lack-of-functions should be well-documented.

I speak as a member of the “doesn’t want to sift through GitHub for scripts” cohort. YMMV.


#117

I’m interested to see the new proposal for dust @tehn had mentioned earlier. I agree with @glia that I like the current script architecture of dust—there’s something about it that feels really community-centric and open. I’m thinking that the UX specifics of how an integration with maiden may happen hinges on that structure.


#118

This is already happening. It’s a requirement before a PR is merged into dust.


#119

also I could definitely see your point @junklight

At work, we have a git integration in our product and it is a rather simple “get latest”. has a few options (branch to get/credential for accessing private repos), but leaves all the publishing/introspecting on things (like changelogs and stuff) to github (or whatever git hosting provider). Including that side of things would probably be a ton of work. I think a “grab the latest dust” and maybe a “hey, there’s new stuff in dust, want to update?” would be quite a useful integration and a lot smaller in scope


#120

Ideally git integration with maiden would happen over a number of commits that introduce small/granular improvements over a longer period of time. Agile/iterative/not-boiling-the-ocean gives the community opportunity to provide feedback as we go and keeps the workload light and easy.


#121

i’m also in that camp but we seem to be discussing different things…

revamping the process of sharing and loading new scripts (which is being reviewed) and revamping the ui structure of script storage (which i think is unnecessary & unwanted by some of us)