Wiki Namespaces?

wim

@espiegel123 said:
I think one needs to let go of feelings of ownership/authorship.

Good point. Generally, anyone can edit any page. Which means one needs to be prepared at the outset for the idea that others might add to or alter their work. I have every expectation that this will be done respectfully and with good will. But some people are more sensitive about such things than others. Best to keep that in mind when considering contributing.

[Deleted User]

@InfoCheck said:

@McD said:
I think I'll give it a couple weeks for these decision to be made the structure. I love the freedom of the wiki as a tool and appreciate the original creators intent to give writers
a way to create organized content where the organization flows from the words used.

If a write uses [[timbre]] and the page saves with a RED link he knows he has to define the term. If it's BLUE someone has created a page. If that page fits the context it's great... if not tweak the link [[timbre_animoog]].

Editors can come along later if these rat's nests which a simply mazes of multiple paths drive them crazy. A wiki can be a maze of multiple paths that is navigated by reading. When reading you might uncover a new word and seek its meaning. A good wiki reader might add [[ ]]'s to the word and create a definition page.

Creating a community of users empowered to use the tools is actually the hardest part.

At this point I’ll post markdown pages on a thread in the knowledge base and if people here decide it’s useful to them if not, they have the ignore feature which @michael has finally broken down and given to us. If people have no use for what I do, I have no desire to foist it upon them. Clearly my naive impressions about wikis as being composed of mini web pages has been panned. When idiot proof instructions are available that I can follow, I’ll be able to fall in line but right now the line seems hazy.

@McD said:

@InfoCheck said:
At this point I’ll post markdown pages on a thread in the knowledge base

I have exactly the opposite idea: avoid the KB until the Wiki arrives. It's here and
there are no rules... just opinions. If @Michael changes that and wants some top down control he'll let us know.

The mic on is on. Use it and just ignore any critics. You've made some excellent progress and are a model for others. There is no wrong wiki page in a democratic system. It's free speech.

I'm not joining any committees anytime soon. But I will follow orders if someone has authority. I won't be happy and will ask for consideration but I will follow the orders.

I personally don’t care if people say I don’t know what I’m doing or doing it in the wrong way, should change it , etc.... I want to be able to make some wiki pages, post them and see if I’m on the right track or not.

Here’s the thread where I’ll be doing that.
https://forum.audiob.us/discussion/32765/proposed-wiki-pages-for-feedback#latest

People’s willingness to provide feedback or not on what’s posted there will be useful too. They’ll just be individual pages, one per post.

espiegel123

Another argument in favor of a very flat architecture is that it will make it much easier (by looking at the sitemap) to see if there is an existing page on the topic you are planning to write about. The more nesting there is, the more due diligence one has to do and the more likely one is to not see that there is already an article covering that topic.

That'll be increasingly true as the wiki grows. In just a few days, a lot of nesting has happened.

Can we agree to create new pages at the top level and stop nesting?

We should all remember to put links in our pages to any pages they refer to.

McD

I think we can make faster progress with some level of management to speed decision making. I will support anyone that volunteers to do the work.

The point about authors not owning content is well stated. I think that makes it clear why
folks want to set some guidelines and educate others early. No one wants to create content
that is rejected or edited without understanding the goals.

Will someone please volunteer and help us move a bit faster towards a good result.

espiegel123

@McD said:
I think we can make faster progress with some level of management to speed decision making. I will support anyone that volunteers to do the work.

The point about authors not owning content is well stated. I think that makes it clear why
folks want to set some guidelines and educate others early. No one wants to create content
that is rejected or edited without understanding the goals.

Will someone please volunteer and help us move a bit faster towards a good result.

Faster than what? We are moving pretty fast.

My suggestion continues to be that people should put pages at the top level rather than nest until we have some loose agreement about which of the namespaces we've discussed that we need.

My revised proposal is that we start minimal:

• playground (which it turns out Dokuwiki creates by default and some indexing/search features know to ignore)
• wiki (which Dokuwiki automatically creates) to house articles related to wiki authoring and housekeeping
• "main" - the top-level namespace. put everything else here. having thought about what people have said, i think it makes sense not to split iosmusic and "knowledgebase" (though I am swayable) for the simple sake of not encouraging proliferation of namespaces and it just makes it easier for people to add pages without worrying where they should go

I asked about whether people think we should have a tutorial namespace. My opinion now is that we don't and just use tags to identify tutorials.

What about users. If we want to encourage people to create pages for/about themselves, it makes sense to me that this be a distinct namespace. But I personally don't know if we want/need that.

In any case, I say go ahead and put content at the top-level. If some pages get moved over the next week or two that won't be a crisis. The Dokuwiki search work pretty well.

[Deleted User]

@espiegel123 Do we not do things like this:

https://wiki.audiob.us/app_tutorials/Sample_Instrument/Piano_Sample_Instrument

But rather:

https://wiki.audiob.us//Piano_Sample_Instrument

And use tags to indicate it’s a tutorial for a sample instrument on iOS piano apps?

Please provide me with an idea about a reasonable number of tags per page as it will help me to focus my content to fit that number and hopefully allow me to create pages that resemble a wiki sensibility rather than a mini webpage.

I will redo the Scythe Synth app tutorial so that it’s more compact instead of spread out over a bunch of pages and the same for other pages I’ve posted with similar structure.

Thank you!

espiegel123

@InfoCheck said:
@espiegel123 Do we not do things like this:

https://wiki.audiob.us/app_tutorials/Sample_Instrument/Piano_Sample_Instrument

But rather:

https://wiki.audiob.us//Piano_Sample_Instrument

And use tags to indicate it’s a tutorial for a sample instrument on iOS piano apps?

That would be my suggestion.

Please provide me with an idea about a reasonable number of tags per page as it will help me to focus my content to fit that number and hopefully allow me to create pages that resemble a wiki sensibility rather than a mini webpage.

In my opinion, use tags as the most important categories. It may take us a little while to figure that out. Don't stress about it too much. We can always add/subtract tags as time goes on. Probably every page needs at least one or two tags. And probably 6 is too many unless the page really cries out for it -- which will be the case for some articles.

That's my take. I am curious what others think.

I will redo the Scythe Synth app tutorial so that it’s more compact instead of spread out over a bunch of pages and the same for other pages I’ve posted with similar structure.

Thank you!

Thank you!!!! You have been doing awesome work. I am sorry if these discussions have seemed critical. We all appreciate what you have been contributing.

Don't worry about the Scythe thing. I don't mind doing it. I think I have a little more to add.

[Deleted User]

@espiegel123 said:

@InfoCheck said:
@espiegel123 Do we not do things like this:

https://wiki.audiob.us/app_tutorials/Sample_Instrument/Piano_Sample_Instrument

But rather:

https://wiki.audiob.us//Piano_Sample_Instrument

And use tags to indicate it’s a tutorial for a sample instrument on iOS piano apps?

That would be my suggestion.

Please provide me with an idea about a reasonable number of tags per page as it will help me to focus my content to fit that number and hopefully allow me to create pages that resemble a wiki sensibility rather than a mini webpage.

In my opinion, use tags as the most important categories. It may take us a little while to figure that out. Don't stress about it too much. We can always add/subtract tags as time goes on. Probably every page needs at least one or two tags. And probably 6 is too many unless the page really cries out for it -- which will be the case for some articles.

That's my take. I am curious what others think.

I will redo the Scythe Synth app tutorial so that it’s more compact instead of spread out over a bunch of pages and the same for other pages I’ve posted with similar structure.

Thank you!

Thank you!!!! You have been doing awesome work. I am sorry if these discussions have seemed critical. We all appreciate what you have been contributing.

Don't worry about the Scythe thing. I don't mind doing it. I think I have a little more to add.

I’m just glad things are moving forward. It’s good people have given me some direction as I do want to create pages people want to use. If I end up redoing the Scythe Synth page before you do, do whatever you want to it as it will be a working example of how wiki authorship works. Spending a lot of time writing and posting pages helped me to learn a lot about the mechanics and more about how the syntax works which it turns out is very different than creating wiki pages consistent with its ethos. I anticipated a lot of my initital efforts would need reworking so that’s just par for the course. It’s never a problem for me to redo things as each time around allows me to learn some more and make adjustments. I do not intend to do this to other people’s pages though as having my finger prints on every page would be really bad for the wiki and for me.

I want to engage in wiki authorship not spamming the wiki so improving pages I’ve already posted seems like the next step.

espiegel123

Btw, I've added a few more handy tips to:

https://wiki.audiob.us/author_tips

including a tip about having a heading and brief intro text at the top of each page and how to suppress the automatic table of contents on a page which is sometimes handy to do.

Will

@espiegel123 said:

@McD said:
I think we can make faster progress with some level of management to speed decision making. I will support anyone that volunteers to do the work.

The point about authors not owning content is well stated. I think that makes it clear why
folks want to set some guidelines and educate others early. No one wants to create content
that is rejected or edited without understanding the goals.

Will someone please volunteer and help us move a bit faster towards a good result.

Faster than what? We are moving pretty fast.

My suggestion continues to be that people should put pages at the top level rather than nest until we have some loose agreement about which of the namespaces we've discussed that we need.

My revised proposal is that we start minimal:

• playground (which it turns out Dokuwiki creates by default and some indexing/search features know to ignore)
• wiki (which Dokuwiki automatically creates) to house articles related to wiki authoring and housekeeping
• "main" - the top-level namespace. put everything else here. having thought about what people have said, i think it makes sense not to split iosmusic and "knowledgebase" (though I am swayable) for the simple sake of not encouraging proliferation of namespaces and it just makes it easier for people to add pages without worrying where they should go

I asked about whether people think we should have a tutorial namespace. My opinion now is that we don't and just use tags to identify tutorials.

What about users. If we want to encourage people to create pages for/about themselves, it makes sense to me that this be a distinct namespace. But I personally don't know if we want/need that.

In any case, I say go ahead and put content at the top-level. If some pages get moved over the next week or two that won't be a crisis. The Dokuwiki search work pretty well.

Good stuff. Agreed. My votes:

yes to users
no to tutorials

Edit: Looks like Docuwiki refers to the top level namespace as 'root'. In your third bullet above, is this what you mean by main? Or would main live off of root?

Will

@InfoCheck said:
The more this drags on the less appealing it is to me as all I’ve received is a lot of confirmation about what I already knew, I don’t know how wiki pages are supposed to be done. Can’t there just be some example pages setup which we can use as a template for making the rest of the pages or point to a page that already has such a setup in place?

Reminder that no one on this thread is getting paid.

wim

@syrupcore said:
yes to users
no to tutorials

Yeh, I agree. I hesitated on “users” because it felt like that might encourage too much self-promotion. But, in reality, there’s nothing to stop people doing that whether there’s a namespace or not. At least this way it may help to segregate content of that type so it doesn’t clutter up the rest.

IMO namespaces are good to go as @espiegel123 has proposed them. The only thing I’d suggest is a barebones outline of possible document types on the home page as a starting place to link documents. Since it’s just a page, that outline can be refined over time, and split into sub pages if it becomes unwieldly.

As for tags, I think thinking of them as a sort of automatic connection builder may be helpful. For instance, if I’m reading a page with a tag “guitar”, I might be interested in seeing other pages with that same tag. Tags may also aid the search engine to rank results, but I’m not sure how much that really applies. So, it’s not so much a question of how many, but of “why” when adding a tag.

Michael

Bravo, guys, great job so far!

[Deleted User]

@syrupcore said:

@InfoCheck said:
The more this drags on the less appealing it is to me as all I’ve received is a lot of confirmation about what I already knew, I don’t know how wiki pages are supposed to be done. Can’t there just be some example pages setup which we can use as a template for making the rest of the pages or point to a page that already has such a setup in place?

Reminder that no one on this thread is getting paid.

Oh I know, we’re quite spoiled by Michael, my own sense of entitlement grows quite rapidly when he dangles music tech goodies like wikis before us even when I don’t know how to play them.

Will

@wim said:
The only thing I’d suggest is a barebones outline of possible document types on the home page as a starting place to link documents.

I'm not following this one, sorry. What do you mean by document types?

As for tags, I think thinking of them as a sort of automatic connection builder may be helpful. For instance, if I’m reading a page with a tag “guitar”, I might be interested in seeing other pages with that same tag. Tags may also aid the search engine to rank results, but I’m not sure how much that really applies. So, it’s not so much a question of how many, but of “why” when adding a tag.

Come around to this thinking as well. Often with folksonomies (at work) we're trying to limit their scope. I think for the AB wiki, folks should just go nuts(ish).

Maybe guidelines something like this for a start:

1. Add a tag for anything relevant on the page. Process, apps used, style, instrument type, concepts...
2. If you make minimal mention of something, skip that as a tag. For instance, a page on capturing loops in AUM that makes a quick mention of trimming the loops in Audioshare and/or Twisted Wave probably shouldn't have a "Audioshare" or "Twisted-Wave" tags.
3. Mind your spelling! We want to avoid having "rozetta", "rosetta" and "rozeta" tags.
4. Separate multiple word tags with an underscore (_) like sample_management

espiegel123

@syrupcore said:

@wim said:
The only thing I’d suggest is a barebones outline of possible document types on the home page as a starting place to link documents.

I'm not following this one, sorry. What do you mean by document types?

As for tags, I think thinking of them as a sort of automatic connection builder may be helpful. For instance, if I’m reading a page with a tag “guitar”, I might be interested in seeing other pages with that same tag. Tags may also aid the search engine to rank results, but I’m not sure how much that really applies. So, it’s not so much a question of how many, but of “why” when adding a tag.

Come around to this thinking as well. Often with folksonomies (at work) we're trying to limit their scope. I think for the AB wiki, folks should just go nuts(ish).

Maybe guidelines something like this for a start:

1. Add a tag for anything relevant on the page. Process, apps used, style, instrument type, concepts...
2. If you make minimal mention of something, skip that as a tag. For instance, a page on capturing loops in AUM that makes a quick mention of trimming the loops in Audioshare and/or Twisted Wave probably shouldn't have a "Audioshare" or "Twisted-Wave" tags.
3. Mind your spelling! We want to avoid having "rozetta", "rosetta" and "rozeta" tags.
4. Separate multiple word tags with an underscore (_) like sample_management

Btw, one can have multi-word tags by enclosing the with quotes. If you think using an underscore is the way to go that's cool. Just thought I'd mention it.

@Michael has changed the Add New Page popup to make it less likely that people will inadvertently put new pages into nested namespaces.

migration note. Over the next several days, I will migrate nested files up to the top-level. So, please don't link directly to nested files from outside the wiki. The movepage tools will make sure that any links inside the wiki get updated. if there are any files that you want to clean up or anything before I move them, give me a heads up.

btw, I am not sure if the notification system is currently working on the wiki. it is possible to subscribe to pages so that you get notified of changes. but i don't know how well that works.

@wim: i wonder if it the outline you mention should be its own page with a prominent link to it on the front page.

Michael

@espiegel123 Have you had issues with the notification system? It's working for me, but I was using the admin level system

espiegel123

@Michael said:
@espiegel123 Have you had issues with the notification system? It's working for me, but I was using the admin level system

I subscribed to a few pages that I made changes to and haven't received a notification -- and I didn't find any in my spam folder. I'll do a couple of more tests and let you know what happens.

wim

@syrupcore said:

@wim said:
The only thing I’d suggest is a barebones outline of possible document types on the home page as a starting place to link documents.

I'm not following this one, sorry. What do you mean by document types?

Sorry, that was confusing. What I meant was just a page that can serve as a starting table of contents. I should have said types of documents rather than document types.

@espiegel123, sure, linking from the home page is a good idea.

espiegel123

@wim: do you want to get something started? I am in the midst of re-acquainting myself with some of the plugins for building dynamic pagelists that might be helpful.

Will

@espiegel123 said:

@syrupcore said:
Maybe guidelines something like this for a start:

1. Add a tag for anything relevant on the page. Process, apps used, style, instrument type, concepts...
2. If you make minimal mention of something, skip that as a tag. For instance, a page on capturing loops in AUM that makes a quick mention of trimming the loops in Audioshare and/or Twisted Wave probably shouldn't have a "Audioshare" or "Twisted-Wave" tags.
3. Mind your spelling! We want to avoid having "rozetta", "rosetta" and "rozeta" tags.
4. Separate multiple word tags with an underscore (_) like sample_management

Btw, one can have multi-word tags by enclosing the with quotes. If you think using an underscore is the way to go that's cool. Just thought I'd mention it.

No strong feelings (though I've a reasonably healthy fear of spaces in all thing web) so long as we suggest some sort of consistent pattern. Just hoping to avoid as much cleanup (clean_up? clean up?) as possible.

Michael has changed the Add New Page popup to make it less likely that people will inadvertently put new pages into nested namespaces.

Noticed this. Big thumbs up.

@wim: i wonder if it the outline you mention should be its own page with a prominent link to it on the front page.

I reckon it should be most of the front page, perhaps along with the tag cloud. Most users will not be authors (guess) so would rather see navigation front and center and contribution guidelines pushed down or called out + linked in a sidebar.

espiegel123

I have moved the page that was in sandbox to the playground directory.

You will notice a few directories appear that dokuwiki creates for its own housekeeping. The talk directory houses the text from page discussions.

[Deleted User]

@espiegel123 I cleaned up the app tutorial pages and posted them to the main directory. Used a tag based structure rather than folders as I did initially. All of the old app tutorial files should be gone. I’ve got a few more misc. pages to move which I’ll do tomorrow.

I cleaned up the Scythe Synthesizer page which I’d made a real mess of, feel free to modify or add to it: https://wiki.audiob.us/ScytheSynth

I tried following the directions for embedding videos and couldn’t get it to work. If someone knows how to do that, it’d be great if they could provide a working example for us to follow.

espiegel123

@InfoCheck said:
@espiegel123 I cleaned up the app tutorial pages and posted them to the main directory. Used a tag based structure rather than folders as I did initially. All of the old app tutorial files should be gone. I’ve got a few more misc. pages to move which I’ll do tomorrow.

I cleaned up the Scythe Synthesizer page which I’d made a real mess of, feel free to modify or add to it: https://wiki.audiob.us/ScytheSynth

I tried following the directions for embedding videos and couldn’t get it to work. If someone knows how to do that, it’d be great if they could provide a working example for us to follow.

thanks. when you are done with the old version of a page, remember to delete the old page's contents so that the old file goes away. (Dokuwiki deletes completely empty pages)

i tweaked the scythe synth page a little bit.

I wasn't sure whether it was better to embed the videos as videos (which uses up more page real estate) or leave them as links.

I've gone ahead and embedded them. What do you all think? Does it take up too much screen real estate?

To embed youtube videos use this syntax:

{{youtube>videoid?parameter1&parameter2|Video Title}}

For example:
{{youtube>BGIL0RJcG4k?medium|The Sound Test Room Overview}}

The various parameters you can use are listed on this page

There is a toolbar icon for adding videos BUT it can only parse this form of youtube URLs

https://www.youtube.com/watch?v=BGIL0RJcG4k

wim

@espiegel123 said:
@wim: do you want to get something started? I am in the midst of re-acquainting myself with some of the plugins for building dynamic pagelists that might be helpful.

Unfortunately I’m tied up until Friday.

[Deleted User]

@espiegel123 said:

@InfoCheck said:
@espiegel123 I cleaned up the app tutorial pages and posted them to the main directory. Used a tag based structure rather than folders as I did initially. All of the old app tutorial files should be gone. I’ve got a few more misc. pages to move which I’ll do tomorrow.

I cleaned up the Scythe Synthesizer page which I’d made a real mess of, feel free to modify or add to it: https://wiki.audiob.us/ScytheSynth

I tried following the directions for embedding videos and couldn’t get it to work. If someone knows how to do that, it’d be great if they could provide a working example for us to follow.

thanks. when you are done with the old version of a page, remember to delete the old page's contents so that the old file goes away. (Dokuwiki deletes completely empty pages)

i tweaked the scythe synth page a little bit.

I wasn't sure whether it was better to embed the videos as videos (which uses up more page real estate) or leave them as links.

I've gone ahead and embedded them. What do you all think? Does it take up too much screen real estate?

To embed youtube videos use this syntax:

{{youtube>videoid?parameter1&parameter2|Video Title}}

For example:
{{youtube>BGIL0RJcG4k?medium|The Sound Test Room Overview}}

The various parameters you can use are listed on this page

There is a toolbar icon for adding videos BUT it can only parse this form of youtube URLs

https://www.youtube.com/watch?v=BGIL0RJcG4k

Your YouTube embed example code template worked for me and the one I had tried in the wiki didn’t.

You can get the correct long YouTube url like:
https://www.youtube.com/watch?v=QBqHm8a68yE&feature=share

1. copying the link from a YouTube video
2. Paste it into the Safari address bar at the top
3. Copy the address and paste it into your wiki page text
4. Select the portion of the url in between the v= and the &feature.
5. Paste the code into the correct location in the link like so:
   {{youtube>QBqHm8a68yE?large|Textastic Tutorial Wiki Upload}}

espiegel123

@InfoCheck : thanks for adding that tutorial. i have a few tweaks to add. I wonder why it didn't work for you initially. Copying the initial share link should provide you with the correct video ID. Pasting into YouTube and having it convert the format is convenient, but I don't think it is necessary.

McD

The structure of the Wiki and the formatting in the Tutorials looks really good.

I could see using the text in one of the tutorial pages with mixed media as a great starting
template for adding new content.

[Deleted User]

@espiegel123 said:
@InfoCheck : thanks for adding that tutorial. i have a few tweaks to add. I wonder why it didn't work for you initially. Copying the initial share link should provide you with the correct video ID. Pasting into YouTube and having it convert the format is convenient, but I don't think it is necessary.

I’m just trying to get things done and that’s what my internet sources told me to do and it worked. The instructions on the wiki didn’t help me in this aspect of the process.

espiegel123

@InfoCheck said:

@espiegel123 said:
@InfoCheck : thanks for adding that tutorial. i have a few tweaks to add. I wonder why it didn't work for you initially. Copying the initial share link should provide you with the correct video ID. Pasting into YouTube and having it convert the format is convenient, but I don't think it is necessary.

I’m just trying to get things done and that’s what my internet sources told me to do and it worked. The instructions on the wiki didn’t help me in this aspect of the process.

I hope you don't mind the tweaks that I made to the page. I updated the instructions to explain a couple of different ways of proceeding. The way you did it works, but you can also extract the video IDs from the other style of URL. So,I thought I'd clarify how to do that for those that don't want re-visit youtube to convert the URL style. (Btw, almost all the embedded videos I've put in started out as the non 'watch?v' style URL)