Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: [wiki] TextBook wiki redesign planning
Oops, just to make this clear. I have not done the upgrade yet
No worries, my misunderstanding. Slow and careful is the right way to go. ;)
so I will perform the upgrade tonight.
By all means.
It’s ridiculously hard to find information on mediawiki. They could really re-organize their documentation site.
No kidding.
Offline
#14 2005-11-16 19:16:09
- ian_ep
- Member
- Registered: 2004-02-29
- Posts: 25
Re: [wiki] TextBook wiki redesign planning
What do you think should be the navigation scheme in the left side?
Basically, everything in the grey boxes should be in the yellow boxes as well – and what is in the yellow boxes should be hidden in some wiki-specific submenu. In other words the main index/navigation should be permanently available in the sidebar. In the current wiki layout I’m constantly paging/scrolling back and forth to the index. I don’t believe I’ve ever consciously clicked on anything currently in the left nav sidebar. I.e. it may as well not be there for day-to-day navigation of the Textbook itself.
Offline
Re: [wiki] TextBook wiki redesign planning
Textbook has been upgraded to version 1.5.2.
I could not get the command line update script to run on Textdrive for some reason, so I had to go the web based route which I had not really tested.
Everything seems to have gone fine but please report any issues. (Previous install is backed up in case we need to backtrack)
Shoving is the answer – pusher robot
Offline
Re: [wiki] TextBook wiki redesign planning
I’m sorry ian_ep, I don’t agree with you. The mockup that Destry has created only shows the main page of the wiki. It’s meant to be the starting point to all the main sections in the wiki. If you have all the links in the sidebar that will simply make it too cluttered. If any more links were to be added into the left navigation, it should probably only be to the top level section indexes e.g. Getting started, Intermediate/Advanced topics, etc.
My only other suggestion from a design perspective is to add a big search bar across the top of the page, either in the header or on top of the contetn area.
From an Information Architecture POV, I do feel that we need to break up the topics further. E.g.
Getting Started With Textpattern- What is Textpattern
- Textpattern Features
- Sections vs Categories
- Pages vs Forms
- etc
I think we need to identify from the outset what content goes where and stick to it. Of course it will be difficult now to move and re-categorise all the stuff we’ve already collected but it will only go to serve us better in the future. Perhaps we may even want to take a page from the Movable Type or Wordpress documentation.
Offline
Re: [wiki] TextBook wiki redesign planning
I think Wiki Starting Blocks should stay. I think it’s important to have section on how to get involved instead of the text in the main body we have now. It might not need to be the top section, but it should be there.
I agree with davidwang that the left nav shoukd reflect the main sections, not necessarily all the options.
The Wordpress Codex seems reasonably close to what we are trying to do.
Shoving is the answer – pusher robot
Offline
Re: [wiki] TextBook wiki redesign planning
ian_ep wrote: In other words the main index/navigation should be permanently available in the sidebar. In the current wiki layout I’m constantly paging/scrolling back and forth to the index.
Yes, this is a recognized problem, has been for a while, and I’ve mentioned many times in the history of TextBook it could not be easily fixed with the version of wiki that was running. We will be changing the navigation. What I was requesting now from people is what links should go in the sides, and I have to agree with davidwang that putting all page links in the navigation is overkill.
davidwang wrote: It’s meant to be the starting point to all the main sections in the wiki.
Exactly. The three divisions are simply a better presentation of the current ToC links such that they target the audiences most likely to use them.
davidwang wrote: If any more links were to be added into the left navigation, it should probably only be to the top level section indexes e.g. Getting started, Intermediate/Advanced topics, etc.
Now that’s a good and sensible idea, and should benefit Ian’s suggestion, if only a bit. We’ll do it.
As for breaking up the topics further, we can certainly do that but we need to know what the topics will be. As it is now, I don’t think we have enough content to see how to properly subcategorize it any deeper than what the chapters already do. But suggestions on this are always welcome. I’m hoping this Document Discussion forum will be a place where the community will suggest what topics they want to be written. From there it will be easier to determine substructure.
On the flipside, I want to delete any pages currently existing that do not have usable content on them. I think we will also be dropping the green and yellow flags too; they are more pollution than helpful.
davidwang wrote: I think we need to identify from the outset what content goes where and stick to it…Of course it will be difficult now to move and re-categorise all the stuff we’ve already collected but it will only go to serve us better in the future.
Yes, it would be nice to organize things in the right direction from the get-go, and now is the time for everyone to speak up about what that is, but it’s not a problem to move things around, now or anytime later, IMO. New faces come to Textpattern all the time, what appears as changed to a veteran will simply come across as how it’s supposed to be for a newbie…it’s all relative. I think it’s more important to move and improve if it’s recognized that indeed improvement is to be gained from the move. Also, we can easily rename page titles too without breaking links, the wiki handles redirects nicely; it’s just a matter of people updating links from the forum and whatnot when they come across a redirect. No big deal.
The WP Codex was brought to attention many times, and the image above is intentionally based somewhat on the codex, though again, I don’t think the codex is perfect and I did not want to copy it; however, it does make a good starting point.
Last edited by Destry (2005-11-17 11:20:51)
Offline
Re: [wiki] TextBook wiki redesign planning
Namespaces (see list of namespaces) are going to be our new friends in wiki management, so all sysops should start becoming familiar here if you’re not already (like me).
“Namespaces among other things allow a separation of content from policy and discussion. They encourage separation of the pages of a wiki into a core set intended for public viewing, and private information intended for the editing community.” —WikiMedia
We’re not really working under a “discussion” and “policy” situation as described, but we should make use of this functionality in ways that suits our purposes since that is what this functionality is intended for.
Basically, these special pages are MediaWiki’s means to manage functional things, such as Navigation and User Roles. They will also be a great way for Admins to communicate about wiki management rather than polluting the public areas with this information. For example, I see this as a good place for documenting admin processes so that future admins have the information without doing a Google hunt for it every time. It seems MediaWiki changes how it does things with each new version, so we should start keeping track of it.
Pat, as soon as I figure out the Userrights namespace, I’ll have you upgraded to sysop. This is a new function in 1.5 that I need to poke at.
Last edited by Destry (2005-11-17 11:56:59)
Offline
Re: [wiki] TextBook wiki redesign planning
Destry wrote:
Pat, as soon as I figure out the Userrights namespace, I’ll have you upgraded to sysop. This is a new function in 1.5 that I need to poke at.
I can yupgrade myself to sysop straight in the DB if you want. I figured out how to do it. A lot of the ways that they suggest making the navigation customizable is to put things in the mediawiki namespace. This would allow us to create as many arbitrary blocks of navigation on the left as we want. It does require modifiying the skin file so I want to try to move that into a textbook skin so it’s easier for future upgrades (since everything will be in one place).
Shoving is the answer – pusher robot
Offline
Re: [wiki] TextBook wiki redesign planning
I can yupgrade myself to sysop straight in the DB if you want. I figured out how to do it.
Good. Go for it. And we should then create the Userrights admin page too, because it doesn’t exist right now and it would be nice to be able to use it later for other sysops, beaurocrats, etc…as well as role assignment. Much easier than poking directly in the database everytime. Even though I have admin, I’m not recognized to access the Userrights page; probably an artifact from the upgrade somehow. We should get that sorted out first.
I think I read somewhere about creating user groups too? That would be a good idea for the existing sysops. Maybe we need to clarify who needs to be a sysop as opposed to a beaurocrat and make two groups accordingly. There seems to be a stronger distinction now in this new version.
Also, let’s start a spot in the wiki for admin-ly type discussion, instead of here. Maybe get that Enotif thingy working for email notifications of new content. Again, I thought of using a non-public namespace for admin communication; no need to give people things to read that don’t need to be. (One of the many new mottos for the wiki).
A lot of the ways that they suggest making the navigation customizable is to put things in the mediawiki namespace.
Right. Understood. I want to stick with the wiki conventions at every opportunity; should make future upgrades smoother. We might as well use the technology correctly.
It does require modifiying the skin file so I want to try to move that into a textbook skin so it’s easier for future upgrades (since everything will be in one place).
Yes, meant to follow up on that with you. Good idea. I should have done that in the beginning. It’s the logical first step before we start new CSS work.
So, I guess a task list is in order? Put my money where my mouth is? ;)
Last edited by Destry (2005-11-17 14:23:12)
Offline
Re: [wiki] TextBook wiki redesign planning
I promise to think of breaking up the topics further over this weekend. Someone call me out ok, so I don’t just grow lazy and forget abt it haha :P
Offline
Re: [wiki] TextBook wiki redesign planning
Destry wrote:
Maybe get that Enotif thingy working for email notifications of new content.
If you look at your user preferences there is an email section that let’s you get notified for page changes etc. Not sure if that’s new but I don’t remember seeing it before.
My concerns with Enotif is that it’s based on 1.5rc4 that’s a few versions behind. Also the FCKEditor integration seems to store all teh entires in html instead of wikitext which I’m not sure if that’s a good idea or not. It seems like we might lose some flexibility. I migth try and see how hard it would be to move to something like insTiki if it has the language support so we could use textile (plus it’s one of the Textdrive hosted products so why not keep it in the family)
Shoving is the answer – pusher robot
Offline
Re: [wiki] TextBook wiki redesign planning
Well, I guess it helps to login (sheesh). OK, I can now see, for example, the Userrights namespace page and such. Yeah, that email notifications I’m pretty sure is new with this version (at least since our last version). That works fine for me, and if that is already built in, all the better. I didn’t realize.
As for Instiki, my feelings are we need action on this, not more debate about platforms (I thought the debate period was over); that’s going backwards. Frankly, the only reason that Instiki has come into this at all is for Textile, and I don’t think putting Textile into place is going to cause a sudden avalanche of writers. When it comes down to it, Textile is just an excuse. There’s many ways to get content into the current wiki, and they all start with the brain and hands. Add Textile and you still have writer’s block (or laziness). No difference.
For practicality’s sake, let’s consider where we are at: We have a platform that you just updated to the latest version that will enable us to do things we could not do before. All we need is to get the navigation in place, create a TxB skin, do a little CSS wizardry, and that’s it, were there, we will have addressed (as I see) most of the real problems that were brought up, and that’s one or two weeks tops at part-time. Porting everything to a new system now seems like much more work to me.
But for the sake of argument let’s lay it down one more time. Assuming Instiki does have language support, and all LGTs (davidm, Inspired, andreas, etc.) are onboard, then I won’t stand in anyone’s way, but it would have to support all the languaes we have already put in motion (and any new ones that are requested). That’s critical. If it doesn’t have the language support, then my feelings are to forget Instiki once and for all. I love Textile as much as the next person, but I don’t want to create a sea of problems simply to use something that perhaps a few people have become too accustomed to. But if you can proof it, want to roadmap it, and whip it into shape, hakjoon, then by all means, we salute you. (Do we need to open up the debate pool again?)
Offline