Slashdot Mirror

But, what web site wants to employ salespeople and (ad) designers when you can just copy and paste a line of code into a web site? Well, I think the ones that continue to do that into the future are the ones that aren't going to make money.

So how should the individual operator of a small web site recoup the cost of a domain, certificate, and VPS? That's the reason that Federated Wiki hasn't become as popular as traditional wiki software such as MediaWiki: each Federated Wiki editor needs his own web site if he wants to share his changes with anyone else.

pre-AOL web

There was no pre-AOL web. Nexus (formerly WorldWideWeb), the first web browser, was first released in December 1990. Quantum Link launched in late 1985, and it changed its name to AOL in October 1989.

The first public wiki, the Wiki Wiki Web* founded by Ward Cunningham which covers soft. eng. philosophy, is trying to go "Federated", but so far users are confused up the wazoo.

A determined "grammar vandal" mucked up the original wiki such that they had to rush out the federated one faster than planned.

Related links:
https://en.wikipedia.org/wiki/...
http://c2.com/cgi/wiki
http://c2.fed.wiki.org/view/we...

* Sometimes known as the "Portland Pattern Repository"

No wikipedia is just that...a wiki...

You're one overworked guy, so forget about a proper trouble-tracking system -- you don't have time to take care of it. You just need a set of web pages that you and the people you support can browse and edit without a lot of hassle. In other words, a Wiki

...upload it as a Wiki, and let the entire world take a crack at it?

This process, akin to the open source development process, is how Wikipedia has accumulated so many factually accurate, well researched, and well written articles.

Warning: also a long rant.

Certainly, in 1995 it was a lot easier to learn how create a web page. You can still use the same HTML of course, but few places teach that - they all want to try and teach new users about CSS, XHTML, DHTML, JavaScript and other buzzwords which only serve to overwhelm people.

Um, the only thing that seems correct is that it used to be a lot easier to become a professional web page author (IMHO). In my experience, most (educational) places want to teach 1995 era web development ... things like massively nested frames, tables, and photoshopped images. Design is an afterthought.

Furthermore, those "buzzwords" aren't really that hard learn at all! XHTML is just a simpler HTML; CSS makes design so much easier; and a little JavaScript is easy as pie (a lot - like any programming language - takes skill). DHTML usually represents methods using JavaScript to change the existing CSS and markup; easy for little cutting-and-pasting. It just seems complicated many developers feel the need to use everything including the kitchen sink. Don't use CSS if you can use templates with PHP or ASP. Don't use JavaScript unless you really need it. HTML 4 still works. Moderation! Moderation! Moderation!

The hard parts about web development are design and consistency. Web browsers in 1995 were not more compliant than now; however, designs were so much simpler that it didn't matter. As I said before, developers nowadays want everything including the kitchen sink. Complex designs take more skill to develop and more testing to work around browser differences. Good design makes it easier to learn to code web sites, but learning to design well is really hard.

A very easy to use but powerful scripting language (something not unlike HyperTalk itself springs to mind), the ability to easily use other native interface widgets - like tabs and menus -, as well as some basic drawing tools (line, rectangle, circle and a basic fill tool spring to mind) together with an easy publishing system should have been the goals for HTML & HTTP IMO.

You're describing the design goals for Java or the X Window System. However, that's not for what hypertext was meant. The World Wide Web is about transferring documents - not programs. Writing documents with (X)HTML, and CSS is easy. On the other hand, writing complex programs with markup and scrips is hard.

IMO we should have a system where - say you are browsing your web site and you spot a spelling mistake on it at http://www.i-like-kibble.org/about.html you should just be able to click an edit button in your browser, be asked to supply a username and password and then have it open webdav://www.i-like-kibble.org/about.html either in a built in editor or it should ask you to select an editor (such as notepad, gedit or even MS Word). When the page is 'saved' in the editor, the changes should be uploaded to the site automatically by the browser. If they had been even remotely competant and argued for this from day one (and hacked up a couple of functional implimentations) we could all have that functionality today.

TBL did have that functionality in mind while writing the original web browser: WorldWideWeb. The W3C's proof-of-concept web browser was designed with exactly that feature built-in. WikiWikiWeb is the popular server version of your vision. The W3C's founders envisioned your suggestion; however, most users simply didn't need or want that functionality. That's one reason why Mosaic and Netscape Navigator were successful despite not having automatic editing capabilities.

And what really annoys me? CSS wasn't even that well designed. It's got huge gaping holes in functionality. You sh

Wiki is in Ward's original description:

The simplest online database that could possibly work.

Wiki is a piece of server software that allows users to freely create and edit Web page content using any Web browser. Wiki supports hyperlinks and has a simple text syntax for creating new pages and crosslinks between internal pages on the fly.

Wiki is unusual among group communication mechanisms in that it allows the organization of contributions to be edited in addition to the content itself.

Like many simple concepts, "open editing" has some profound and subtle effects on Wiki usage. Allowing everyday users to create and edit any page in a Web site is exciting in that it encourages democratic use of the Web and promotes content composition by nontechnical users.

Historical Note. The first ever wiki site was created for the Portland Pattern Repository in 1995. That site now hosts tens of thousands of pages.

• http://c2.com/cgi/wiki?WelcomeVisitors
• http://c2.com/cgi/wiki?WikiHistory
• http://c2.com/cgi/wiki?WikiDesignPrinciples

TWiki - here's an example, Parrot. There are plenty of references around explaining the what a wiki is. It is up to you to use it.

Good point. As with many Ask Slashdot questions, this one jumps ahead to a possible solution without really describing the problem. Perhaps he's thinking in terms of enabling users with no HTML knowledge to share information. If so, there are better solutions. For example, Wikis are easy to use and trivial to administer. Though it sounds like Piecewise is looking for something more sophisticated.

Are you sure MT is what you really want? I'll bet a wiki would be a better choice; we just installed one here at work and we're going crazy-go-nuts with it. We've installed PhpWiki, but Twiki looks useful, too.

The "home" of wiki is at http://c2.com/cgi/wiki, and the main book on the subject of wikis, The Wiki Way, has a companion website with downloadable code at http://wiki.org/.

Briefly, a wiki is a website that allows one to create and edit web pages without having to mess with accounts and permissions--just type in one's text into an edit box, click "submit", and it's up and running. We use it as a knowledge base, and I'm going to use it to record billable events and notes.

"The simplest possible database that could possibly work"--Ward Cunningham

Warning: the book was originally bundled with a CD with all the Perl source files in Mac format. (Sad how often this happens.) Perl interpreters on other platforms don't grok this, so they withdrew this printing and replaced it with a corrected version. The screwed-up version was sold off to remainder houses. You can save money buying the screwed up copies, but you have to convert the files, or download corrected files.

I suggest looking at setting up Wiki. Collaborative writing with ability to make links inside and outside the wiki and the ability to edit each other's texts which will put a different spin on the nature of the collaboration. Also, the sheer simplicity of it will focus the students on the content rather than on playing around with a bunch of software widgets.

I agree. "Open Source" in biology is more the rule than the exception.l I have been astounded by the FREE resources out there available for anyone to use! Databases like Genbank and Swiss-Prot are invaluable to modern molecular work. Pedro's Biomolecular Tools is just a sample of the plethora of free resources available today.

Incidentally, I can't recommend Ensembl highly enough. Not only have I been able to significantly further my research with their tools, but they have open-sourced the entire code behind their site! And the documentation is even in Wiki! I really think what they have done is incredible and should be one of the first projects anyone mentions when expounding the virtues of open-source software as well as sharing information in the field of Biology.

-Ryan

Tim Berners-Lee, in his book Weaving the Web and in articles about the Semantic Web talks about his original concept of the web consisting of internal (two-way) as well as external (standard) links, and page editing being interactive; and of how market forces and the then available technology diluted this concept into today's model of the web.
Nowadays, server-based software such as Wiki and variants make collaborative web editing possible, but mass practical application of internal linking is still a long way away, due to issues of trust and synchronization, although steps are being taken in this direction as well.

Nicely bound books that open flat and have a bit of margin-room for notes. The cover needn't be elaborate or thick or anything, heck a nice bit of plastic would do just as well. Headings that make sense and are at the top of each page. Even better Chapter / Subject / Topic on each page top.

Along with this I'd like a decent web site, something that contains the full text of the book with corrections & updates highlighted on a changes-page as well as in the body. Personally I don't see these as competing with the bound version of the book but if need be have some sort of coupon or registration system but put that web site up.

I'd also really like it if there were some sort of Wiki or other notes system attachable to the various parts of the online book where other readers can put their own notes and share them, pointers to other resources, updates etc. This would require some sort of administration I realize but would immensely add to the value of the book, presumably be a good sales medium for related products.

Along with this a Bayesian logic "Help Engine" would be most appreciated. Half of the time I know that whatever is in the book, I just can't find it. A "wizerd" guiding me to the right spot drawing on the index and glossary would be most appreciated.

Finally, and this seems terribly trivial to me but it is so rarely done: I'd like to be able to type in the page number of my bound book (in URL)and jump right to it in the online version, check for updates etc. I know I can drill down to it from the online index but page numbers are useful markers and can be trivially used as pointers in the online version.

Oh, and having worked with any nuber of non-native anglophones over the years a button for machine-translating a page on the website into whatever else is availiable would also help many of those folks. It may not be the best quality translation but sometimes it's enough to kick the mental gear far enough it all makes sense. Going to a 3rd-party service for the translation is a hassle, building in a translate link would be useful.