I've been following this thread with interest, and the wiki seems like a great direction (thanks @rs2000 !). The top-page structure looks like a good starting point for scaffolding the rest of it in an organized manner (and probably a good template for @parkerfrost 's proposed navigation column, if/when that materializes). I will very be interested in the organizations of the top-level recipes/tips/tricks page along the same lines.
I was naturally all fired up to start contributing the moment I logged in, but upon reflection it's probably a Very Good Idea to keep it read-only for a fews moments to think about/set up some simple organization guardrails (layout/tags/review/etc) before motivated individuals (like me) start injecting a bunch of content/potential chaos on their own initiative.
I'm very optimistic about this development—it's true that in-app documentation is sparse in spots, but a wiki like has the potential to go way beyond that—especially since wiki pages can hyperlink to external resources (including forums discussions like this) for further reference and nuance. And forum discussions (like this) can then link back to the articles in the wiki!
In reference to earlier discussion, I wouldn't be too concerned about lack of participation on Drambo wiki compared to fate of the AudioBus one (which it wasn't well-known or very focused)—Drambo users by their nature seem much more motivated than the general iOS music app population to work out and share details on how things work and what to do with them (and how to put that in a wiki).
It would be a very excellent feature to allow users to add their own Help text to individual Presets (ala the Library browser's "?" button), especially for Rack presets.
Over time, I forget the intended usage/quirks/etc of racks I've built or downloaded from PatchStorage. I know there are the Misc/Text Box and Misc/Section (foldable) modules, but they take up rack space and very few people have ever used them for that (and tbh, that's not where I'd expect to find Preset docs when the Drambo UI already displays module help in the Library window)
I was naturally all fired up to start contributing the moment I logged in, but upon reflection it's probably a Very Good Idea to keep it read-only for a fews moments to think about/set up some simple organization guardrails (layout/tags/review/etc) before motivated individuals (like me) start injecting a bunch of content/potential chaos on their own initiative.
Trying to think of how to say this without putting anyone off. I really don't mean to discourage input of any kind, so I hope it's not taken that way.
Changing the appearance of the wiki can be done at any time, non-destructively. Changing the structure is more difficult and gets increasingly so over time. So getting started on the right foot as far as the content structure goes is far more important than style changes. As long as the content is created with consistent use of categories, tags, and heading levels, etc, putting the spit and polish on the look of it can be done site-wide and non-destructively at any time.
My only input on the structure at this time is it feels a bit monolithic. The auto generated table of contents helps a lot, but walls of text sometimes put people off, especially in this "Great, but can you make me a video?" age.
That said, splitting up a page into sub pages is better than consolidating a site with too many pages.
thanks to the plain text format, I think that splitting a structured page like the long list of modules could still be done later (by creating new separate pages where the "----" and "===== Name =====" would act as separators.
Next week, I'll play with tag based searches. Ideally, each module could have its own page and a search with all tags would return the full list of modules.
@rs2000 That sounds really good to me! Certainly a great way to get started. If we find it should be different then that changing later won’t be a huge headache.
Tag search works pretty well over on the Loopy Pro wiki ... as long as people are conscientious about tagging things.
Do tags work within pages though? I've only worked with them for finding pages, not for finding sections within pages as would be needed if larger all-inclusive pages are the norm.
I'm going to set up a local Doku Wiki here at home so I can experiment. I may pop in with some suggestions or be able to help if you run into technical questions about how to do things.
[edit] up and running in under 10 minutes. I have to say, I can tell already that Doku Wiki kicks MediaWiki's butt in terms of ease of setup, more accessible storage, and performance. 😎
@number37 Absolutely, it's really a well done solution made with love.
If tags don't work within pages, I wouldn't mind to split the respective page into separate pages with tags, hoping that I'll be able to build a search function that will present all pages that match the selected tags, as one page.
Feel free to edit on the wiki directly by the way.
I have one suggestion at this point. I think it would be more practical to at least break the main page up into separate pages at the application level - what are now the top level headings of Drambo, Sunrizer, Dagger, Zeeon, iSequence and Combustor.
You could also consider creating a sidebar page that would contain the top level links to those master pages and other high-level topics. Sidebars are handy because they're available from every page, whereas a table of contents varies unless you stick with a purely monolithic page. I think my preference is also biased just based on being used to sites having one, so you might want to ignore that suggestion.
Doku makes it simple to try out anyway. Just create the sidebar page (there's a link to it already on the doku/welcome page at install) and put some content there. You can remove the sidebar at any time by just deleting all the content in that page.
I'm only tossing out initial reactions. I'm just as happy if they're not taken up. 😎
I'll see if I can find out what plugin they use for the tag search on the AB wiki. It does list all the tag hits on one page, though not with a fully assembled page, but with only short page summaries. Tagging is done by adding the tags in a special section at the bottom of the page. Not everyone does this because it's not completely obvious how to do it.
I'm mostly holding off on editing on the live wiki until the structure is settled. The stuff I'm doing on my home wiki you wouldn't want me to mess with on your live site: experimenting with templates, plugins, style changes, etc.
https://www.dokuwiki.org/faq:sidebar has some useful information. It's pretty simple though as long as the template has builtin sidebar support (the default template and the one I mentioned via PM do). Just add content to the sidebar page and the sidebar will appear.
I have a few suggestions for the structuring of the Modules page itself. Right now it's in a flat list all on one page and the table of contents for the page consumes more than one screenfull in itself. I think the page should be organized at least with headers by module type. IMO it would be even better split into sub pages per module type, but I'm open to any structure.
I created a page in the playground to dump a few thoughts I had, and as a suggestion for how we could have a page to discuss structure, administration, formatting, etc. These are just some thoughts I've had exploring Doku Wiki on my own server.
One index page that shows all modules only by name
Grouped into categories
Each category has its own page with a list of modules, descriptions and links to usage examples
I would keep the examples on separate pages, but another option is to show modules in context with neighbor modules in the first place, to show a typical usage scenario
@rs2000 I like your approach to breaking it down into different parts, but I would suggest we change the scale or granularity of some of them.
Basic Index (alphabetical list of names of all modules and nothing more) — this could be its own page, or it could live nested with another page, ie. a page about modules, or a general introduction to working with modules in Drambo. Format it in multiple columns to save space.
Module list — a page with names of every module (formatted with emphasis), organized by category (formatted as subheadings), with the briefest possible description of each module. This page could be organized as a table, or as a bunch of headings, or as a long nested bullet list.
Detailed module info — Individual pages for each oscillator, with descriptions of each input, output, and control that the module has. There could be a subsection for example patches/techniques using the given module. But I think it would be better to put all the example patches in a separate section of the wiki, and just link to them on the module info page. This way, a technique that uses two or more different modules could be referenced on both of the module pages, without duplicating information.
Patch examples — (see my comments above)
In this kind of scenario, I find that categorization is most useful when it organizes information within a page, but it can become unhelpful if you can only access a relevant bit of information by drilling down to a level that hides the other categories. So that's why I'd like to include basic descriptions of all the modules on a single page. It makes it easy to cmd+f search and find the term you're looking for, easier to skim, and easier to quickly glance back and forth between a couple different modules. A user who doesn't know what the name of a module means will get a lot of value out of this. I don't want to have to click on one page for Sampler, go back and then click on the page for Flexi Sampler, go back and then click on the page for Shot Sampler just to learn what makes them different.
@number37 I really like what you’ve done here. Very easy to parse! I feel like I can get around it without much thought and that’s the main thing that matters. @rs2000 I feel like that’s a solid level of granularity I see @aaa point and perhaps we can marry the two.p? Ie a module overview page that links the in depth page for each module? If that ends up being clunky I’m more in the index to independent pages camp.
I'm big on organization an getting started on the right foot, but not much good at suggesting how things actually should be organized. Some of the comments led me to suggest taking a peek at the DataTables Plugin, which adds the capability for sortable tables. I think plugins should be keep to a minimum in general, but it might be worth considering if a table-based index is under consideration.
I'll test this one out on my home DokuWiki to see if it at least seems stable and potentially useful.
As for patches, there's already the patchstorage.com repository. I wouldn't fork that off to a repository on the wiki, except possibly for quick example patches to illustrate a point or tutorial. I'd keep the main patch repository, with more "production ready" patches where it is and just link to them from the wiki.
I also wouldn't attempt to have a comprehensive list of even patch links on the wiki _unless there's someone with the time and motivation to keep it up to date_. There's a nice index of Mozaic patches on the LoopyPro wiki, but it has a very thorough and dedicated person who created and maintains it. It's way more helpful than trying to find patches on patchstorage.com itself, but if it wasn't so carefully maintained, it'd be more hinderance than help.
Speaking of the Mozaic Scripts List above, it may be worth looking at its organization. It seems similar to some of the suggestions here for the Modules index.
Comments
the colors are weird
Green: Linked page exists
Red: Linked page doesn't exist yet
I've been following this thread with interest, and the wiki seems like a great direction (thanks @rs2000 !). The top-page structure looks like a good starting point for scaffolding the rest of it in an organized manner (and probably a good template for @parkerfrost 's proposed navigation column, if/when that materializes). I will very be interested in the organizations of the top-level recipes/tips/tricks page along the same lines.
I was naturally all fired up to start contributing the moment I logged in, but upon reflection it's probably a Very Good Idea to keep it read-only for a fews moments to think about/set up some simple organization guardrails (layout/tags/review/etc) before motivated individuals (like me) start injecting a bunch of content/potential chaos on their own initiative.
I'm very optimistic about this development—it's true that in-app documentation is sparse in spots, but a wiki like has the potential to go way beyond that—especially since wiki pages can hyperlink to external resources (including forums discussions like this) for further reference and nuance. And forum discussions (like this) can then link back to the articles in the wiki!
In reference to earlier discussion, I wouldn't be too concerned about lack of participation on Drambo wiki compared to fate of the AudioBus one (which it wasn't well-known or very focused)—Drambo users by their nature seem much more motivated than the general iOS music app population to work out and share details on how things work and what to do with them (and how to put that in a wiki).
On the subject on in-app documentation:
It would be a very excellent feature to allow users to add their own Help text to individual Presets (ala the Library browser's "?" button), especially for Rack presets.
Over time, I forget the intended usage/quirks/etc of racks I've built or downloaded from PatchStorage. I know there are the Misc/Text Box and Misc/Section (foldable) modules, but they take up rack space and very few people have ever used them for that (and tbh, that's not where I'd expect to find Preset docs when the Drambo UI already displays module help in the Library window)
@C__
I was naturally all fired up to start contributing the moment I logged in, but upon reflection it's probably a Very Good Idea to keep it read-only for a fews moments to think about/set up some simple organization guardrails (layout/tags/review/etc) before motivated individuals (like me) start injecting a bunch of content/potential chaos on their own initiative.
Exactly my thoughts! 😊
Nonetheless, I've added a sketchpad
to add anything that comes into your mind.
It looks like a great start. 😎
Trying to think of how to say this without putting anyone off. I really don't mean to discourage input of any kind, so I hope it's not taken that way.
Changing the appearance of the wiki can be done at any time, non-destructively. Changing the structure is more difficult and gets increasingly so over time. So getting started on the right foot as far as the content structure goes is far more important than style changes. As long as the content is created with consistent use of categories, tags, and heading levels, etc, putting the spit and polish on the look of it can be done site-wide and non-destructively at any time.
My only input on the structure at this time is it feels a bit monolithic. The auto generated table of contents helps a lot, but walls of text sometimes put people off, especially in this "Great, but can you make me a video?" age.
That said, splitting up a page into sub pages is better than consolidating a site with too many pages.
Cheers @rs2000 - Happy to help out!
+ 1 on everything said here.
Great start! Thanks for getting this going.
Thanks @number37 and @offbrands,
thanks to the plain text format, I think that splitting a structured page like the long list of modules could still be done later (by creating new separate pages where the "----" and "===== Name =====" would act as separators.
Next week, I'll play with tag based searches. Ideally, each module could have its own page and a search with all tags would return the full list of modules.
But maybe there are better options?
@rs2000 That sounds really good to me! Certainly a great way to get started. If we find it should be different then that changing later won’t be a huge headache.
im color blind
green looks just like red ;)
red and green are never the colors to go for ;)
Tag search works pretty well over on the Loopy Pro wiki ... as long as people are conscientious about tagging things.
Do tags work within pages though? I've only worked with them for finding pages, not for finding sections within pages as would be needed if larger all-inclusive pages are the norm.
I'm going to set up a local Doku Wiki here at home so I can experiment. I may pop in with some suggestions or be able to help if you run into technical questions about how to do things.
[edit] up and running in under 10 minutes. I have to say, I can tell already that Doku Wiki kicks MediaWiki's butt in terms of ease of setup, more accessible storage, and performance. 😎
@number37 Absolutely, it's really a well done solution made with love.
If tags don't work within pages, I wouldn't mind to split the respective page into separate pages with tags, hoping that I'll be able to build a search function that will present all pages that match the selected tags, as one page.
Feel free to edit on the wiki directly by the way.
I have one suggestion at this point. I think it would be more practical to at least break the main page up into separate pages at the application level - what are now the top level headings of Drambo, Sunrizer, Dagger, Zeeon, iSequence and Combustor.
You could also consider creating a sidebar page that would contain the top level links to those master pages and other high-level topics. Sidebars are handy because they're available from every page, whereas a table of contents varies unless you stick with a purely monolithic page. I think my preference is also biased just based on being used to sites having one, so you might want to ignore that suggestion.
Doku makes it simple to try out anyway. Just create the sidebar page (there's a link to it already on the doku/welcome page at install) and put some content there. You can remove the sidebar at any time by just deleting all the content in that page.
I'm only tossing out initial reactions. I'm just as happy if they're not taken up. 😎
I'll see if I can find out what plugin they use for the tag search on the AB wiki. It does list all the tag hits on one page, though not with a fully assembled page, but with only short page summaries. Tagging is done by adding the tags in a special section at the bottom of the page. Not everyone does this because it's not completely obvious how to do it.
I'm mostly holding off on editing on the live wiki until the structure is settled. The stuff I'm doing on my home wiki you wouldn't want me to mess with on your live site: experimenting with templates, plugins, style changes, etc.
Thumbs up for a side bar that's available on all pages!
https://www.dokuwiki.org/faq:sidebar has some useful information. It's pretty simple though as long as the template has builtin sidebar support (the default template and the one I mentioned via PM do). Just add content to the sidebar page and the sidebar will appear.
The sketch pad is read-only for me.
@number37 Sorry, fixed.
ooooh. 𝔜𝔬𝔲'𝔯𝔢 𝔦𝔫 𝔱𝔯𝔬𝔲𝔟𝔩𝔢 𝔫𝔬𝔴 ... 𝖒𝖚𝖆𝖍𝖆𝖍𝖆𝖍𝖆.
Have we decided on a general format for the modules yet? I’d love to start adding to the wiki soon
I have a few suggestions for the structuring of the Modules page itself. Right now it's in a flat list all on one page and the table of contents for the page consumes more than one screenfull in itself. I think the page should be organized at least with headers by module type. IMO it would be even better split into sub pages per module type, but I'm open to any structure.
I tried a little bit of alternate formatting in https://www.beepstreet.com/bwiki/doku.php?id=playground:modules, but it was only preliminary exploration while waiting decisions about organization and format.
I'm ready to go too once the groundwork is laid.
I created a page in the playground to dump a few thoughts I had, and as a suggestion for how we could have a page to discuss structure, administration, formatting, etc. These are just some thoughts I've had exploring Doku Wiki on my own server.
I'm not married to any of these thoughts. I'm just putting them down in case anyone finds them useful, and in the hope that others will join in.
That looks good @number37, thanks!
What about this:
Opinions?
@rs2000 I like your approach to breaking it down into different parts, but I would suggest we change the scale or granularity of some of them.
In this kind of scenario, I find that categorization is most useful when it organizes information within a page, but it can become unhelpful if you can only access a relevant bit of information by drilling down to a level that hides the other categories. So that's why I'd like to include basic descriptions of all the modules on a single page. It makes it easy to cmd+f search and find the term you're looking for, easier to skim, and easier to quickly glance back and forth between a couple different modules. A user who doesn't know what the name of a module means will get a lot of value out of this. I don't want to have to click on one page for Sampler, go back and then click on the page for Flexi Sampler, go back and then click on the page for Shot Sampler just to learn what makes them different.
@number37 I really like what you’ve done here. Very easy to parse! I feel like I can get around it without much thought and that’s the main thing that matters. @rs2000 I feel like that’s a solid level of granularity I see @aaa point and perhaps we can marry the two.p? Ie a module overview page that links the in depth page for each module? If that ends up being clunky I’m more in the index to independent pages camp.
It's nice to see the discussion moving forward. 😎
I'm big on organization an getting started on the right foot, but not much good at suggesting how things actually should be organized. Some of the comments led me to suggest taking a peek at the DataTables Plugin, which adds the capability for sortable tables. I think plugins should be keep to a minimum in general, but it might be worth considering if a table-based index is under consideration.
I'll test this one out on my home DokuWiki to see if it at least seems stable and potentially useful.
As for patches, there's already the patchstorage.com repository. I wouldn't fork that off to a repository on the wiki, except possibly for quick example patches to illustrate a point or tutorial. I'd keep the main patch repository, with more "production ready" patches where it is and just link to them from the wiki.
I also wouldn't attempt to have a comprehensive list of even patch links on the wiki _unless there's someone with the time and motivation to keep it up to date_. There's a nice index of Mozaic patches on the LoopyPro wiki, but it has a very thorough and dedicated person who created and maintains it. It's way more helpful than trying to find patches on patchstorage.com itself, but if it wasn't so carefully maintained, it'd be more hinderance than help.
Speaking of the Mozaic Scripts List above, it may be worth looking at its organization. It seems similar to some of the suggestions here for the Modules index.