Wikidot Community

Thank you, Ed!!!

And of course by then putting it in a div and styling it you can create an actual button:

[[div style="-moz-border-radius: 5px; background-color: #dddddd; border: 1px solid #38360E; text-align:center; width: 100px;"]]
[[button files text="Upload Photos"]]
[[/div]]

Rob

Thanks, Rob, I will write down this and use it in some other projects, since this time I need only a small link.

Rob, using that code you just posted, I've styled my "Upload skins!" link a bit better than what I had previously, at the very top of this page: http://cyclods.wikidot.com/download:skin

As it's the start of a collapsible block… that causes a few issues for me though. I'm wondering if you or anyone else could point to some solutions:

• How to make the text in the collapsible block bold, but the actual collapsible content regular font
• How to make the text in the collapsible block centre-aligned, but the actual collapsible content as left-aligned

Doing something like this doesn't seem to work:

[[div style=" text-align:center; font-weight:bold; "]]
[[collapsible show="show me" hide="hide me"]]
[[/div]]

...
[[/collapsible]]

The Div block is applied to the whole collapsible content, despite the closing div tag in there.

As an alternative though … if you have any other suggestions that may be completely different, I'd like to hear them. All I wish to do is to make that button as obvious as possible, whilst not distracting someone that is just there to download and not to upload anything.

Maybe using a collapsible block is the wrong idea, due to the styling restrictions? A popup, perhaps?

..
..

Oh, and originally, I had the width equal to about 150 px, which looked perfect as a button. The problem was that the whole collapsible contents was squashed inside of that 150px wide block, meaning that it looked strange, and I've since changed width to be 100%.

Can you post a mock-up of what you're looking for? We can't view your page source, so I'm having a harder time wrapping my head around what it is you want.

Does inline styling or extra divs not work the way you want?

----
[[div style="text-align:center; font-weight:bold;"]]
[[collapsible show="show me" hide="hide me"]]
[[/div]]
this should be centered and bold
[[/collapsible]]
----
[[div style="text-align:center; font-weight:bold;"]]
[[collapsible show="show me" hide="hide me"]]
[[/div]]
[[div style="text-align:left; font-weight:normal;"]]
this should be left-aligned and normal
[[/div]]
[[/collapsible]]
----

Okay, the text align works fine, and so does the font weight. Exactly what I want.

However, is there a way to make the button width 150px, but the content 100% of the page width when it is expanded? The way it is now, the collapsed content expands to 100% of the previously-defined 150px width.. which is not what I wanted :/

And if I manually define a width, e.g. 500px, the content uses that width but the background block does not.

[[div style="-moz-border-radius: 15px; background-color: #dddddd; border: 1px solid #38360E; text-align:center; width: 150px; font-weight:bold;"]]

[[collapsible show="Show content" hide="Hide content"]]

[[/div]]
[[div style="text-align:left; font-weight:normal; width:500px;"]]

This is the text that appears within the collapsible block.
This is the text that appears within the collapsible block.
This is the text that appears within the collapsible block.
This is the text that appears within the collapsible block.
[[/collapsible]]

[[/div]]

This might help… this is what I'm aiming to achieve if possible (or something like it):

Probably not exactly what you had in mind, but this is an interesting look:

[[div style="-moz-border-radius: 15px; background-color: #dddddd; border: 1px solid #38360E; text-align:center; width: 150px; font-weight:bold;"]]

[[collapsible show="Show content" hide="Hide content"]]

[[/div]]
[[div style="-moz-border-radius: 15px; background-color: #FCF2C4; border: 1px solid #38360E; text-align:left; font-weight:normal; width:500px;"]]

This is the text that appears within the collapsible block.
This is the text that appears within the collapsible block.
This is the text that appears within the collapsible block.
This is the text that appears within the collapsible block.
[[/collapsible]]

[[/div]]

BTW, I like your technique of using the tabview with the new page modules. Very clean! have you had any issues where the user forgets to select the proper category first?

-Ed

That looks… interesting. I'll have to look at a way to make it fit the site better (colours, etc) but will most likely use that.

The collapsible block includes a page called skin:_upload, which has this code:

[[tabview]]

[[tab Games]]
[[module NewPage category="skin" button="new skin" parent="download:skin" tags="games"]]
[[/tab]]

[[tab Movies]]
[[module NewPage category="skin" button="new skin" parent="download:skin" tags="movies"]]
[[/tab]]

[[tab Music]]
[[module NewPage category="skin" button="new skin" parent="download:skin" tags="music"]]
[[/tab]]

[[tab Tech/Websites]]
[[module NewPage category="skin" button="new skin" parent="download:skin" tags="tech/web"]]
[[/tab]]

[[tab Team Cyclops]]
[[module NewPage category="skin" button="new skin" parent="download:skin" tags="default"]]
[[/tab]]

[[tab Everything else]]
[[module NewPage category="skin" button="new skin" parent="download:skin" tags="unsorted"]]
[[/tab]]

[[tab Not CycloDS]]
[[module NewPage category="skin" button="new skin" parent="download:skin" tags="nonCyclo"]]
[[/tab]]

[[/tabview]]

I've only added the tabview recently. Before that I just had one NewPage module after another on the page and it didn't look good. Considering that I'm forcing people to choose one category or another… it lowers the number of mistakes being made. I'm hoping that with data forms, I can let people select a category using a combo-box.

Generally people put their pages in the right category — if they don't it's easy enough just to change the tag :)

Although I could allow multiple tags, I decided not to, for simplicity. So the categories are hard-coded in and regular users can't edit the tags after initially creating the page (that being part of the reason that the page options are hidden, meaning that you can't view the source code either)

I agree, Scott. Also, after selecting your files the "Upload" button is hidden below the file list if your page has any length to it at all and you have to scroll the window to expose it.

I still like to use the old uploader when I'm replacing a file since it offers the option to overwrite the existing file as opposed to automatically renaming it with file(n).ext. The link to the old uploader is harder is even harder to get to than the "Select Files" button.

-Ed

Agreed. The file upload system needs a massive redesign IMO, to appear similar to how the notificiation pop-ups do.

And I also use the old uploader:

• When wanting to overwrite a filename
• When I'm behind a corporate firewall, and the normal one doesn't work

Don't I know it. And I know you've thought about it too, Shane.

lumpers, splitters, and filters

I used to think the human race was basically divided into lumpers and splitters, and in any complex network involving many objects, ideas, and people, I cast my lot with the splitters. Because without meticulous categorization and heirarchical organization, how would you ever find anything or define any discussion of it?

But we are sooo past that question, especially in our internet age, and especially especially in a bottom-up, crowd-sourced model like a wiki. Consistent splitting is just too maddeningly difficult when you're dealing with lots of material, lots of unsupervised volunteers, and not much conscious consideration for other people's systems. Assuming community engagement is foremost, then lumping is inevitable, and it's filter, search, and access privileges that slice through the gordian knot of too much unstructured data. The Wikidot community is a classic example — I wish we did a better job at structuring our ListPage filters to make useful lists, and then to rely on admin-only tags and crowd-sourced rating and ranting to emphasize priorities.

Go West, young man

To some extent, we do these things. We create, filter, and prioritize here in the Community. But we have a dominant nomadic (might I say American?) tendency to create new spaces, to use them till they become over-populated and overly cluttered, and then we abandon them in favor of some new, cleaner, untrammeled venue. Our Wikidot cognoscenti perpetuate the ongoing (negative) frontiersman pattern of abandoning old spaces and staking out new wikitopias where they plan to do the community's business — hatch bold new ideas, discuss, create new lists, build new tools, and continue to chip away at the huge body of work that results.

It usually happens like this:

• A highly-functioning Wikidotian announces, "Compatriots! Follow me! Let's organize our best thinking over here."
• That's an attractive proposition, and a cadre of other wikizens load up their newfangled feed-readers and join the wagon train. In their Brave New Wiki, they contribute their knowledge and skills, often to great effect.
• Sometimes the new space is explicitly restricted to certain users. Mostly, participation is restricted by default, because most of the community hasn't yet figured out where the action is.
• But inevitably, the wishlists and the bug reports get longer, more complicated, more redundant, more ponderous — especially as more users learn this is where the real work is happening. That's when we start seeing alerts like —

"Don't even think of posting your help requests here. Those belong in the community. "

• Eventually, we're again mired in huge long, cumbersome discussion threads, and again it's again difficult to coordinate the workflow.
• At which point, a highly-functioning Wikidotian announces, "Compatriots! Follow me! Let's organize our best thinking over here."

But what have we left behind?

When we follow our wiki-frontiersman urges and shift the community's work to one or several new sites, we sever ties. We leave behind a body of work: institutional memory, outdated content (and therefore often confusing content), and the remains of so many unfinished project ideas. But more importantly, we leave behind people. It sounds kinda trite to say it, because hey, this is the internet, and my desktop can take me anywhere at all. But for many users — for most newbies and many experienced wikiphiles too — when we move regularly, they lose focus, and we lose them.

To my mind, the biggest loss is this: by moving the center of activity away from the Community site, we diminish the ties between the highly-motivated and skilled guru Wikidotians and everybody else. By design, our experts engage less frequently with the community's users and its content. And when the rest of the unwashed wiki-masses come to the Community seeking to better themselves and their own wiki-spaces, they're perplexed and confounded by the multiplicity of spaces where questions are lodged and where enlightenment resides. In the Community, they're deprived of the insights of many wiki-gurus, whose attention is now focused elsewhere.

The uninitiated might stumble on any number of pages, categories, and sites, some still active, others just the remains of ruined wiki-settlements of yore…

• The Pro ;-) site,
• The Community's Wish list
• my own wistfully neglected favorite: the Spelling Corrections page.
• Pieter's highly entertaining blog with its WeNeed list.
• the projects site.
• Not to mention the official Wikidot and community-oriented sites about Themes, FAQs, and on and on.

Solution?

Maybe we've struck upon a workable solution in the projects site, which seems to pull together a bunch of prototype sites and creative Wikidot community sites into one overarching framework. Maybe the magic of Cross-Site Includes and melded RSS feeds will eventually help to reconnect so many lost linkages. But I've been hanging around for a couple years now, and I regularly get lost looking for stuff around here. And disorientation is a big obstacle to participation.

So here's my request — could we please keep our nomadic yearnings in check, and whenever possible, let's please center our work in the Community site.

End of rant. Please discuss.

I read 3/4 of that, skipped the rest. Good rant!

(hehehe) Care to post that on pieter's blog in a tuesday rant though? ;-)

http://blog.wikidot.com

… but the last 1/4 was the best part!

Thanks for reading. Another possible example of this "frontiersman pattern"/syndrome is the new approach to discussion in the projects site. Most wikis coordinate discussion in branched threads, which admittedly can get long, complex, and cluttered. In the projects site, the approach is to formally split these threads, at least at the first level, into various threads attached to their own new pages.

For complex projects collaboration, I suppose this makes some sense. But the downside is that it doesn't feel intuitive, and I haven't yet figured out how to navigate it smoothly. So it's difficult to gauge the scope of the larger discussion. and it's not clear to me how I'd track any future threads related to a certain project. It's a localized example of "frontiersman", because users are constantly encouraged to pick up and plant their ideas somewhere new and untouched. While it's a clearer "splitting" mechanism, it has many of the downsides I described before.

I haven't used Google Wave yet, but maybe the projects site is trying to approximate that. The way I understand Wave, it's possible to massage discussions, isolate their subthreads, and dynamically manage their complexity. But I think the user interface is more intuitive in that case, so that it's easier to find your way back to the bigger picture. If our wiki-gurus are to abandon the centralized discussion board in favor of these structured page-related threads, I sense it'll be even more difficult for the typical user to keep track.

This is the point, where at this site the old community …

Genau, Helmuti. Referring to "old community" is classic frontiersman-speak. It's like all those germanic settlers in America who moved on from "the Old Country". Initially they maintained ties with their Heimats, but eventually they centered in their new places and lost sight of their origins.