Unsolved new wiki - pagenames / namespaces

[This N°9]

I start this thread to have a place to fix the places/names for pages on the new wiki. I found some (links) where I'am not sure if they point to the correct place, or if this fits the original idea of the namespace - structure:

this should be fixed as quick as possible, because these links also appear in the templates, and will be re-used now again and again:

links on :home:mbhp (should they be in 'mbhp' namespace or in 'home' namespace?)

I post them as they are now:

[[.:etching_pcbs]]

[[.:mbhp:parts]]

[[.:mbhp:skills]]

[[.:mbhp:preparation]] move [[:stryd_one_preparation]] and should be broken up and compiled with [[:home:basics]] as required //what has to go where?

[[.:soldering]]

[[.:constructing_enclosures]]

[[.:mbhp:troubleshooting]]

[[.:troubleshooting_apps]]

maybe durisian can give the right answers

[Just Phil]

maybe some of those should be in a Getting Started namespace and you wouldn't need to have them under every module.

[Durisian]

There are no right answers... :)

I thinks strydys preparation page needs to be broken up into more specific parts - rather than one generalisation. What goes where.... Give it a go, if we don't like it we'll change it later - a start is better than not at all.

troubleshooting + skills - maybe the same as prep, needs to be broken up... mmm... not convincesd... pass. Both are too general to put in mbhp.

soldering is a skill...

maybe...

[[.:skills:etching_pcbs]]

[[.:mbhp:parts]]

[[.:skills:preparation]]

[[.:skills:soldering]]

[[.:skills:constructing_enclosures]]

[[.:troubleshooting:home]]

[[.:troubleshooting:mios]]

[[.:troubleshooting:mios32]]

[[.:troubleshooting:midi]]

[[.:troubleshooting:hardware]]

[[.:troubleshooting:apps16]]

[[.:troubleshooting:apps32]]

??

sorry phil - at work... maybe once the rehearsal gets under way...

The point of having them in every module/project is so a newbie can start with the MB64 page and work their way through it - rather than having to find all the info first

[Just Phil]

skills is logical and short...

[This N°9]

I like just phildurisian's proposition.

one question is if parts should be in mbhp, but I think it's the right place.

sorry for my short absence, my internet connection is currently very weak, maybe somebody is

standing on a cable somewhere.. I come to chat.

[This N°9]

The point of having them in every module/project is so a newbie can start with the MB64 page and work their way through it - rather than having to find all the info first

agree to that. the links will be in the module/project template already prepared, so this takes no extra time when adding a new page. All the links in the template should be updated accordingly then.

I like your spirit Just Phil. I think you are the right man to the right time  ;)

[This N°9]

I propose a litte modification:

[[:home:troubleshooting:home]]

[[:home:troubleshooting]] //entry page for troubleshooting. all the other troubleshooting pages are linked there

same for skills. skills - entrypage links to sub-pages. maybe the skills entry-page could be linked on the project page then, instead of

multiple skills-pages.

[stryd_one]

My preparation page was the beginnings of a personal blog, also somewhere for me to keep my notes... I'm happy for it to be broken up and used as general documentation if there's anything useful there.

[[:home:troubleshooting:home]]

[[:home:troubleshooting]] //entry page for troubleshooting. all the other troubleshooting pages are linked there

Do it.

One ting I would suggest is... Don't spend too much time waiting for the go-ahead. You guys, in my eyes at least, have been consistently getting it right. I'd say: docs first, ask questions later ;) Unless you really aren't sure of course; the team is always there to advise, IF you need it. But mostly, I don't think you guys need it - I think that waiting for advice is holding you back. Unleash the wiki demons! Go! :D

[This N°9]

@stryd_one

Do it.

did it..  :). thanks for your trust

in fact all the content from new_wiki_layout is copied (and modified) to home:* now. I tried to fix some links and tidy up the namespace concept at some points:

-home

--about

---faq

----xxx (if needed)

---midibox (What is a MIDIbox)

---ucapps (Introduction to uCApps.de)

---mbhp_acronyms (MBHP Acronyms)

and.. skills namespace prepared (links on the pages). So now the whole stuff can be built upon the existing pages. If somebody feels that we are doing crap, just make an intervention. I think the namespace-concept is quite tight now, and can serve as a solid base. of course it can always be expanded, or pages can be moved if required.

[Durisian]

yehaa!

Twinny - Is it possible to rename the actual root to something other than home - like midibox

at the moment in 'You are here' we get Home >> home >> etc >> etc

[stryd_one]

When the overhaul is final, the :home:home page, will be moved to :home, then the 'you are here' will be right :)

[stryd_one]

Okay I've just moved this' images to the new page location. Had a few thoughts along the way:

new_wiki_layout:mios32

new_wiki_layout:mios

new_wiki_layout:projects

new_wiki_layout:community

new_wiki_layout:about

These should hang off of wikify: now, not New_wiki_layout, right? The new_wiki_layout and it's children have been like a template for the wiki, it really should stay around someplace... What about like:

wikify:home (was :new_wiki_layout)

wikify:home:mios32

wikify:home:mios

wikify:home:projects

wikify:home:community

wikify:home:about

Also, these two fellas:

http://www.midibox.org/dokuwiki/doku.php?id=home:mios

http://www.midibox.org/dokuwiki/doku.php?id=home:mios32

These are kinda uhm... they need some work to make it 'flow' a bit. I think that's probably something I should line up for, if you guys are OK with that? It needs to be broken down into Use and App Development, and tools and such, but there are common tools between them. Lots of grey area. Got any ideas? I'm just gonna take a stab at it tomorrow night. I'll drag over a bit of stuff from the old app dev pages too. So, jump in if you've got ideas!

Last thing... I think we're trifling with a position where we are not going to know what's done and what's not... it might pay to try and do whole sections at a time (provided it doesn't get a bit mind-numbing which I know it can).. Like, if you're gonna do the MBSId page, make sure you get all the MBSID info from across the wiki before you move onto another thing like MBFM or something...

Perhaps alternately we could start to rip out the old pages in advance? As in... once you copy the MBSID page from the old wiki layout, edit the page, and replace all the text with a link to the new page. Leave a keyword n there, like TRASHMARKER, then when we're done we can run a search for trashmarker, and delete them at will. Will make the cutover easy.... We can always revert to the old version of the page to get it back if needs be, by running the same search...

I dunno, we just need some way to know if we've hit that page or not.... It's a pleasant change to have so many chefs, now we just have to be careful not to spoil the broth ;)

[This N°9]

These should hang off of wikify: now, not New_wiki_layout, right? The new_wiki_layout and it's children have been like a template for the wiki, it really should stay around someplace... What about like:

wikify:home (was :new_wiki_layout)

for me 'wikify:template:home' would be the logical place to put it. (also for the other ones, like: 'wikify:template:home:about'). what do you think? could also be flat ('wikify:template:home', 'wikify:template:about', 'wikify:template:project', 'wikify:template:module').

general question: is it really necessary to keep all these templates? maybe just some of them, or additionally a 'general style principels' page would do it, something like a styleguide page.

Perhaps alternately we could start to rip out the old pages in advance?

hmm.. I don't know. The new wiki would be linked to the one that is live, say a project-page is linked from the old wiki, on this page then you have links to modules etc., maybe you will land on pages that are not finished etc.

I know, some projects (mine as well) in the new wiki are already linked on the old projects page, but if I think about it again, it's maybe not a wise thing to do..

I dunno, we just need some way to know if we've hit that page or not.... It's a pleasant change to have so many chefs, now we just have to be careful not to spoil the broth

This again would be a good argument for "cut/paste" instead of "copy/paste" old pages. One alternative would be to add comments in the source code of the old pages that will not be visible on the rendered page, like "all info on this page was totally moved etc..".

The problem about this would be, that new info could go to pages, that are already marked as "done", so maybe stryd's proposition is the best solution.

[Just Phil]

what about adding a MB parts library area, to allow users who have made parts in various software to share them with the rest of the community.. to save people time..

for example, i'm working on a layout in solidedge, and it takes me alot of time to make a simple encoder  or pot, then to make the knob, then the slider, then the slider knob.. while i know that other users on this forum have already made these same parts. this would make it alot easier for newbs to simply take pre-made bits and layout their Midiboxen.

i'm sure other cad users feel this would speed everything up as well...

[Twin-X]

yehaa!

Twinny - Is it possible to rename the actual root to something other than home - like midibox

at the moment in 'You are here' we get Home >> home >> etc >> etc

? I get you are here Home>>etc>>etc

Changed allready? And i can change home into anything you like :D

[This N°9]

and it takes me alot of time to make a simple encoder  or pot, then to make the knob, then the slider, then the slider knob.. while i know that other users on this forum have already made these same parts.

aehm.. explain that to me. I usualy buy the parts somewhere.. do you design knobs/buttons etc? If yes, this could be a very interesting thing.

[Just Phil]

aehm.. explain that to me. I usualy buy the parts somewhere.. do you design knobs/buttons etc? If yes, this could be a very interesting thing.

no no what i meant was for example we should have a wiki space with links to files like this (taken from uCapps DIN Module page)

http://www.ucapps.de/mbhp/alps_stec16b03.lbr "Eagle Library for Alps STEC16B03, provided by Jack"

that way when working on boards you have the perfect footprint and model of the Alps encoder....

since in my case i'm designing a mb64e layout. alot of the parts were designed already....

dstamand made this layout in solidedge.

he then added this image which shows dimensions of each pot, encoder and internal bit. this would save everyone quite a bit of time modelling the same parts all the time.

http://s113401185.onlinehome.us/utopia_live-v1.0.pdf

now since i'm working on a case that will have alot of components in it... (g5 xserve, liquid cooling,  many knobs, more buttons, sliders, etc.) and i want to fit all the components in a 65mm tall enclosure. (think all in one studio)

Inside all of the components will need to just barely dodge each other to make this work.

and when i'm done i'd like to share my library of components, so someone could for example re-use them in their designs...

since most of us use the same few brands of pots, and knobs etc... eventually we will have a whole library of components specific to midibox...

i dunno, let me know if i made any sense there.

[stryd_one]

Things like the parts footprints for a specific app, should really be listed under that specific app's page.

This is one of the things I wanted to sort out with the mos/mios32 pages - the toolchains are all over the place :/

For example, the toolchain docs I've written are intended to be a sequence of docs, but have been added as one-offs...codeblocks is listed under core toolchain, and it's not part of the core toolchain at all, it's an option. There's no real space for things like eagle, kicad, solidedge, etc, yet (maybe in skills?)

Where should we put that kind of thing?

[This N°9]

dstamand made this layout in solidedge.

wow, this looks really nice.. I like those purist designs.

[Durisian]

This is one of the things I wanted to sort out with the mos/mios32 pages - the toolchains are all over the place :/

For example, the toolchain docs I've written are intended to be a sequence of docs, but have been added as one-offs...codeblocks is listed under core toolchain, and it's not part of the core toolchain at all, it's an option.

sorry, i've been kind of thinking aloud by just doing - and then having to work so I get stuck before finishing (I'll try to curb this poor form) - ide's weren't meant to end up as one offs, just cross-platform compatible pages (but I didn't get that far)

perhaps core toolchain needs to be changed to just 'toolchain' with a few options -

toolchain:core

toolchain:codeblocks

toolchain:etc

There's no real space for things like eagle, kicad, solidedge, etc, yet (maybe in skills?)

home:software ?

[stryd_one]

sorry, i've been kind of thinking aloud by just doing

Suits me fine man! Sorry I didn't mean to diss your work, it's not like that... You've laid a good starting point but there's just this one thing that's a bit skewed... And it's no coincidence, it's a tricky category to handle (I should know, I've walked this path before ;) )

cross-platform compatible pages

Cool that was something I've been trying to weigh up too.

perhaps core toolchain needs to be changed to just 'toolchain' with a few options -

toolchain:core

That's what the core_toolchain should be.

Problem is, is that windows, or linux, or mac, or a mix? The 'core' toolchain basically means the compiler, assembler, linker... and the installation procedure differs from one platform to another. Same deal with codeblocks... but the usage is the same for either. That's why I was thinking that there needs to be an installation page for each OS, for each tool,

home:software  ?

Yeh, but the toolchain is software too...

I can't help but wonder if the software and toolchain should go together in a new namespace like this, and not in the mios/mios32 pages. Another reason to go that way, is that the toolchain setup may be a little different if you want to install toolchains for both platforms.

If we have a home:software page and namespace, is it likely to clash with anything else? Is it likely to make things too complex? (maybe it can fit elsewhere)

What do you think?

[stryd_one]

So, I need answers on two things:

:Software:

:Skills:

Speak now or I'll make it happen ;)

[stryd_one]

I'm going a bit crazy on the wiki tonight. Should be some changes done within the next few hours.

We *really* need to get on top of a way to flag the old pages when we have migrated their content to the new pages.

If noone has any ideas, I'm just going to start flagging them with a comment up the top.

[stryd_one]

Oh and guys, two things that' I've so far spent over two hours cleaning up:

Headers: USE the H1 header throughout the pages. Trust me, it's easier to add lower layers, that redo a whole page's headers later.

wikify pages: Make sure you update the templates FIRST, THEN change the stuff in :home to reflect it. There are  afew spots where the template doesn't match the real thing already.

[Max Romantschuk]

I'm going a bit crazy on the wiki tonight. Should be some changes done within the next few hours.

We *really* need to get on top of a way to flag the old pages when we have migrated their content to the new pages.

If noone has any ideas, I'm just going to start flagging them with a comment up the top.

Maybe a redirect would be best? But that depends on how hard it would be to access the original old page if need be after the redirect was created.

I've been trying to wrap my head around it, but what is the core benefit of doing this big old page to new page thing as opposed to simply improving the existing wiki incrementally? For instance Wikipedia seems to have solved most indexing issues with dedicated list pages, linking to individual pages. I'm not saying one or the other is better, but I'm just curious as to why exactly a total refactoring would be so much better than incremental improvements?