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.
@number37@rs2000@aaa The mosaic scripts list mentioned looks like the perfect balance to me! Lots of keywords for page searching - pleasing layout to look at - extensible if we found we wanted to add a tags column or something. What do others think? I’m all for it
Thanks for all the work and insight on this @number37
Just for fun, I did a quick test of some summary table formatting on my home wiki. This was to test the DataTables plugin. I think I prefer the look of the non DataTables method. It might be marginally more trouble to maintain though because additions must be inserted in the order they will appear. On the other hand the DataTables plugin adds some interesting features.
The Mozaic Scripts List breaks the tables up into separate sections rather than using spanning columns as I did in the example. That might be the best as headings will automatically generate the table of contents and make the table maintenance easier to use.
You can check the page out if you like. I'll take it down once the page structure is decided.
The "simple" one is more readable, in terms of the way that all modules of the same Type are presented in a way that groups them together. The other more advanced DataTables method is more "busy" in appearance and not quite as easy to skim with the eye, but the filtering ability makes it easier for the user to filter out unnecessary information. But the user-controlled sorting is overkill in this context, IMO. I can't think of any reason someone would alphabetize by description. And switching between alphabetic order by Type vs alphabetic order by Module name won't be needed either, if we keep the info on the basic index page alphabetized by module, and the table on this page grouped by Type.
@parkerfrost have you had a look at the approach used in the Mozaic Scripts List? I sort of think that kind of hybrid approach would be better for this. Rather than one huge table with a bunch of spanned rows to be careful to format right, breaking the list up into separate tables per module type might be better.
As for the look, that's all a function of the Wiki styling. Tables are just entered with a plain text syntax and the wiki software does the rest.
I can't figure out how to log in and begin editing on mobile. But after seeing this comment from you, I tried on my desktop and found a button to log in at the top of the page. Seems like editing is only enabled for the playground page, which is fine for now. When I start adding info, I guess I should stick to the same format/style that's already in use there. I thought people generally approved of @number37's table formatting, but if that's more complicated to implement I'll hold off on that for now too.
EDIT: AHA! To log in on mobile, click the Tools section hear the top of the page, and then Log In will appear at the bottom of a drop down menu!
I thought people generally approved of @number37's table formatting, but if that's more complicated to implement I'll hold off on that for now too
I've only been tossing out suggestions and an example or two. I'm ready to put more time in once the show is officially on the road. If anyone has editing questions, etc, I may be able to help out.
Comments
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.
@number37 @rs2000 @aaa The mosaic scripts list mentioned looks like the perfect balance to me! Lots of keywords for page searching - pleasing layout to look at - extensible if we found we wanted to add a tags column or something. What do others think? I’m all for it
Thanks for all the work and insight on this @number37
Just for fun, I did a quick test of some summary table formatting on my home wiki. This was to test the DataTables plugin. I think I prefer the look of the non DataTables method. It might be marginally more trouble to maintain though because additions must be inserted in the order they will appear. On the other hand the DataTables plugin adds some interesting features.
The Mozaic Scripts List breaks the tables up into separate sections rather than using spanning columns as I did in the example. That might be the best as headings will automatically generate the table of contents and make the table maintenance easier to use.
You can check the page out if you like. I'll take it down once the page structure is decided.
https://wiki.warehouse13.freeddns.org/playground:datatables
(note, I know the "branding" is a copyright violation. The wiki is normally for private use only.)
Looking good. 👍🏾
These tables are BEAUTIFUL !
The "simple" one is more readable, in terms of the way that all modules of the same Type are presented in a way that groups them together. The other more advanced DataTables method is more "busy" in appearance and not quite as easy to skim with the eye, but the filtering ability makes it easier for the user to filter out unnecessary information. But the user-controlled sorting is overkill in this context, IMO. I can't think of any reason someone would alphabetize by description. And switching between alphabetic order by Type vs alphabetic order by Module name won't be needed either, if we keep the info on the basic index page alphabetized by module, and the table on this page grouped by Type.
How do we edit the wiki? I was able to log in but I can't figure out how to make changes or add suggestions.
@number37 The tables look amazing. That truly seems like the best of both worlds! @rs2000 what do you think?
@bcrichards the sandbox section of the wiki is the only one editable right now as the general format is still being hammered out.
@parkerfrost have you had a look at the approach used in the Mozaic Scripts List? I sort of think that kind of hybrid approach would be better for this. Rather than one huge table with a bunch of spanned rows to be careful to format right, breaking the list up into separate tables per module type might be better.
As for the look, that's all a function of the Wiki styling. Tables are just entered with a plain text syntax and the wiki software does the rest.
@number37 Yeah the mosaic scripts system makes a lot of sense to me! Really nice for quick navigation
Agreed, it's clean and strightforward.
I didn't know the Mozaic page before, and I like the short categories overview and how the uploads are split into categories.
Would be fine for me!
Please try again 😊
Ok I was able to edit the playground page.
Haven't seen any action in this thread in a while. What still needs to be done before the wiki can open for contributions?
Editing should be possible already!
Doesn't it work for you?
I can't figure out how to log in and begin editing on mobile. But after seeing this comment from you, I tried on my desktop and found a button to log in at the top of the page. Seems like editing is only enabled for the playground page, which is fine for now. When I start adding info, I guess I should stick to the same format/style that's already in use there. I thought people generally approved of @number37's table formatting, but if that's more complicated to implement I'll hold off on that for now too.
EDIT: AHA! To log in on mobile, click the Tools section hear the top of the page, and then Log In will appear at the bottom of a drop down menu!
For others who want to make contributions, this is where it's happening https://www.beepstreet.com/bwiki/doku.php?id=playground:playground
I thought people generally approved of @number37's table formatting, but if that's more complicated to implement I'll hold off on that for now too
I've only been tossing out suggestions and an example or two. I'm ready to put more time in once the show is officially on the road. If anyone has editing questions, etc, I may be able to help out.