Topics

locked Wiki


 

Hi All,

I've been working on wiki functionality, but I'm stuck and I need some help deciding what to do. If you don't know what a wiki is or does, this post probably won't make much sense; apologies for that.

As I have it now, the wiki consists of HTML pages, editable with the standard wysiwyg editor that is used to compose posts on the site. I like this much better than other wikis that require you to know markdown or some other wiki formatting code. It feels right to me. But there are a couple issues.

First issue is that part of a wiki is the ability to show the differences between edits to a page, to see what's changed (aka a diff). Doing a diff on two HTML pages is problematic, and I'm not sure I can create a page that will show the differences nicely. It's much easier to do a diff on two pages that are composed using markdown or some other wiki formatting code. One solution to this is that when doing the diff I could first strip the HTML. That would show the differences in text, but not formatting. Another solution is that I could not use HTML and go instead with markdown or something else. But that makes creating wiki pages more difficult.

The second issue involves sortable tables. Ideally, I'd like the wiki section to take the place of both the Links and Database sections in Y! Groups. That feels like the right thing to do to me.. To do that, you need to be able to create tables and be able to sort them in different ways. Wikipedia has a sortable table that does just this; but they use their own formatting code to do it. Again, I can solve this problem by not using HTML pages and instead using a different markup format. The other solution is to not try to combine the wiki and links/database section; I'd create a separate, dedicated database section. This has its own set of plusses and minuses.

Those are the two issues I'm wrestling with at the moment. Thoughts or suggestions would be appreciated!

Thanks,
Mark


 

"Again, I can solve this problem by not using HTML pages and instead using a different markup format" - why not add a particular class to the HTML table and apply sortability to any table with the class?


 

Hi Mark,
I'm using PBWorks wikis to document the history of Marconi Radar in a collaborative fashion.

I'm not competent to comment on the coding requirements, but here are my impressions as a user.

For me the way PBWorks does the change report is entirely adequate, viz. full detail of textual changes but "Only Formatting Differences" (undefined) where there has been no substantive change.

I also like the way PBWorks has the ability to opt for a sortable table with the sort being user-defined up or down by selected column.

HTH,
Ian

On 11 December 2014 at 23:23, Mark Fletcher <markf@corp.groups.io> wrote:
Hi All,

I've been working on wiki functionality, but I'm stuck and I need some help deciding what to do. If you don't know what a wiki is or does, this post probably won't make much sense; apologies for that.

As I have it now, the wiki consists of HTML pages, editable with the standard wysiwyg editor that is used to compose posts on the site. I like this much better than other wikis that require you to know markdown or some other wiki formatting code. It feels right to me. But there are a couple issues.

First issue is that part of a wiki is the ability to show the differences between edits to a page, to see what's changed (aka a diff). Doing a diff on two HTML pages is problematic, and I'm not sure I can create a page that will show the differences nicely. It's much easier to do a diff on two pages that are composed using markdown or some other wiki formatting code. One solution to this is that when doing the diff I could first strip the HTML. That would show the differences in text, but not formatting. Another solution is that I could not use HTML and go instead with markdown or something else. But that makes creating wiki pages more difficult.

The second issue involves sortable tables. Ideally, I'd like the wiki section to take the place of both the Links and Database sections in Y! Groups. That feels like the right thing to do to me.. To do that, you need to be able to create tables and be able to sort them in different ways. Wikipedia has a sortable table that does just this; but they use their own formatting code to do it. Again, I can solve this problem by not using HTML pages and instead using a different markup format. The other solution is to not try to combine the wiki and links/database section; I'd create a separate, dedicated database section. This has its own set of plusses and minuses.

Those are the two issues I'm wrestling with at the moment. Thoughts or suggestions would be appreciated!

Thanks,
Mark



 

Mark,

One solution to this is that when doing the diff I could first strip the
HTML. That would show the differences in text, but not formatting.
That seems reasonable. I agree with Ian that PBworks has a lot right with how they do things, including the page history and comparison of revisions.

The second issue involves sortable tables. Ideally, I'd like the wiki
section to take the place of both the Links and Database sections in Y!
Groups. That feels like the right thing to do to me..
I thought so at first, and maybe still do for the Links. But the pre-Neo database had some useful tricks that might be hard to emulate in a Wiki table. Or maybe not, but one wouldn't ordinarily think of them in a wiki context.

One was to have separate authority to 1) add rows, 2) see rows, and 3) format the table. It was possible to give the moderators to determine the format of the table (including number of columns and column descriptions) while allowing members to add rows and edit their own rows only (not the rows added by other members).

It was even possible to give members the ability to add rows but not to see other members' rows - this effectively created a "drop-box" capability where members could share information privately with the moderators.

And, these detailed privilege settings were defined on a per-table basis. Or, perhaps the fact that these are per-table privileges provides the escape hatch necessary to allow this to work in a wiki environment. But that also opens up the question of what view/edit privilege controls should exist for a) the wiki feature as a whole and b) on a per-page basis.

Another set of useful capabilities came and went with the "Groups Labs" applications. Those were essentially extended function tables, where the columns were typed, had descriptions and edit hints, and other aspects of a more powerful database than the simple text cells of the regular Yahoo Groups Database feature. Didn't go as far as being relational though, nor being able to pull in content from the Members list or other inherent tables of the group.

To do that, you need to be able to create tables and be able to sort
them in different ways. Wikipedia has a sortable table that does just
this; but they use their own formatting code to do it.
As Ian said, PBworks does this too. They use what looks (in Source edit mode) like ordinary HTML table elements but declared with

<table class="pbSortable" ...

which presumably clues something in the page render to implement the table sort ability. I don't like the fact that the sort markers in the header row (arrows) don't show until you first click in a header row. If the capability is there the affordance should be evident.

Again, I can solve this problem by not using HTML pages and instead
using a different markup format.
I think most users will be best served with a WYSIWYG page editor, regardless of the underlying representation. With that in place it may be less important what markup language (HTML, markdown, ad-hoc) is behind it.

The other solution is to not try to combine the wiki and links/database
section; I'd create a separate, dedicated database section. This has its
own set of plusses and minuses.
As hinted above, an advantage of a dedicated database section is that it makes wrangling the metadata clear: you can have a page view for each entry (row) that exposes metadata like author and date/time even if those aren't columns in the table view. And there's a clear meaning to the log entries that would go with editing a row's content or the table format.

I think if the table capability were wrapped in a wiki page that might be really powerful for some purposes, but I would want to preserve all the metadata power that the database form offers, something that PBworks' tables don't even aspire to do.

Those are the two issues I'm wrestling with at the moment. Thoughts or
suggestions would be appreciated!
One other feature of the PBworks' pages that I really love is the Table of Contents widget. Very handy indeed.

-- Shal


Frances
 

It's been a few years since I created or maintained a wiki, but I liked Wikispaces. I was able to use the simple wiki I created to demo wikis as part of my job in the public library. Someone else set up a PBwiki but either the preferences they set up or the format they chose made it difficult to use. (I see that Wikispaces is no longer offering free non-educational wiki space.)

All I am looking for is a simple way of creating an index to a few pages, each with a list of external links on each page. Static web pages (or blog posts) would work just as well for our purposes. For example, with Wordpress, I can choose to create pages or posts. Pages can have subpages. 

I don't know the answer to this, and I am not sure what other people need from this. 

I just looked at the info you gave for files, Mark. What format “files” need to be in? Can they be files with HTML so that there are clickable links? 

Just wondering whether a wiki is overkill for what we need.




Nightowl >8#
 

Weighing in on the Wiki/Database discussion.

Many of the Yahoo Groups users have been stymied from finding a new Groups location simply because there was no database/spreadsheet option.

I don't understand Wikis and I didn't  use the database personally, (although my members did in MM), but I promise you, if you add a database function, you will win hands down. I can guarantee that, as a 130,000 member group of high school students and twenty-somethings deleted their groups on Yahoo over that loss.

And they aren't the only ones.

Brenda
Nightowl >8#


Duane
 

Besides having a way to revert to a previous version of a Wiki page, I feel that having changes be moderated might prevent some problems. Many folks aren't familiar with how a wiki works, including me, and could make a mess or delete a lot of work accidentally. Being able to compare the pending revision to the existing page would be important.

I'd much rather have Databases be a separate area. I don't think I'd have any trouble using wiki pages to set up links.

Duane


RS
 

I think a dedicated database section is best as well.  In addition to it's popularity and familiarity, the tools that can be leveraged in a database-exclusive section would not be restricted by any wiki-related considerations, which would make both features more flexible.  I personally don't need sortable tables in a wiki, though it's a fun idea.  If I needed that level of power in relation to a group wiki, then inserting a link on the wiki page to the relevant group database page would be just fine. Since links can already be set to open in new windows, no back and forth navigation is required of the user. Easy enough.

Another thought is that while "wiki" conveys a clear idea of the concept you are aiming for, it also carries certain expectations with it, such as a certain style of edit history, markups, etc. It may also carry stigma for users who wouldn't know how to code one, expecting more difficulty than WYSIWYG. I would prefer to see the WYSIWYG interface retained if possible, as it is much easier to work with.  Perhaps what you are really making with this section is not a true "wiki", and should thus have a different name?  Its "wiki-esque", but regular wiki admins may be disappointed that the regular markup features aren't there. I think for example that Google Groups calls their version "pages", if I recall correctly.  Similar functions to a wiki, but all wysiwyg.  

It's a new animal, you can give it a new cage. :)

I would also agree the wiki would work fine as a "links" area, and offers a more versatile way to display *some* data in tables, but ultimately, from what you describe, it sounds like it's going to create undesirable work and possibly restrictions on both features, and so the better power lies in separation. At least for now.  

As for my own usage needs, I am just waiting to be able to insert pictures in the wiki section.  That will be all the toy I need for some time.

Thanks for all your thoughtful work on this.


RS
 

Ooops!  I'm dumb.  Turns out the wiki totally accepts drag and drop images.  Works very nicely, and they can be resized easily.   It didn't when I first tried it, but works fine when I tried it on a different computer.  Thanks Mark!


Frances
 

Hi

Mark fixed this a couple of weeks ago.

Frances

On Jan 24 15, at 6:27 PM, dalemonator@... wrote:

Ooops!  I'm dumb.  Turns out the wiki totally accepts drag and drop images.  Works very nicely, and they can be resized easily.   It didn't when I first tried it, but works fine when I tried it on a different computer.  Thanks Mark!


Duane
 

I thought of another function for the Wiki that might be useful. In addition to moderation of modifications, allow the owner/moderator to Lock /Unlock each page if Subscribers have "view and edit" permissions. Very important pages (group guidelines, FAQ ?) could be locked while still allowing collaboration on many other things.

Duane


 

On Thu, Jan 29, 2015 at 5:33 AM, Duane <txpigeon@...> wrote:
I thought of another function for the Wiki that might be useful.  In addition to moderation of modifications, allow the owner/moderator to Lock /Unlock each page if Subscribers have "view and edit" permissions.  Very important pages (group guidelines, FAQ ?) could be locked while still allowing collaboration on many other things.

Thanks, added to the list.

Mark 


 

Duane,

In addition to moderation of modifications, allow the owner/moderator to
Lock /Unlock each page if Subscribers have "view and edit" permissions.
I agree, this would be very useful.

This would be akin to the ability in (Classic) Yahoo Groups to set access control on a per-table basis in the database and on a per-album basis in Photos.

-- Shal