Re: [Phpwiki-talk] bugfix, db schema, thoughts on navigation

[Steve W. <sw...@wc...>]

On Sat, 10 Jun 2000, Arno Hollosi wrote:

> Btw, the whole issue about "[" is pretty much a usability nightmare.

No surprise, again... from now on you can just describe them to me if you
wish, and I'll try to wrap my brain around them. We agree that freeform
links aren't necessarily good for a Wiki, but some people want them and I
was curious to experiment with it.

I have been planning on bracketing the code in if() {} statements, and
users can configure the Wiki to allow them. (It should ship with them
turned off by default). Also I want to use your regexps for a
Mor3F3x1bl3 l1nKing5tyl3. :-)

> I.e. "[[ some text \n more text]" renders as "[["  (\n = linebreak)

Too bad for the user, linebreaks aren't supported in any Wiki, are they?
;-)

> But getting to the point:
> I guess we should set us some achievable goals for the 1.2 release so
> that we don't wander around aimlessly. Also, we should consider not to 
> overdo it, as too much functionality is not a good thing.
> 
> The way I see things, the main goal for 1.2 is the new DB schema and
> the slew of functionality this entails.

Yes, that was my intention for the most part; in fact I want to make it
even easier and say that 1.2 is the release with the (almost) normalized
database schema, and even the new functionality can wait until we're sure
the old code base is stable on top of the new DB libraries. 1.2.1 could
have more features, if we wish; but I would make the short list to be:

1. New schema implemented
2. New linking optional, disabled by default
3. Old Wiki code base (the display) is stable
4. Old linking revisions: (I may need clarification on this)
  Images just need a URL in brackets []
  Arno's Wiki linking also in brackets [] (will this collide with 
  freeform linking?)
5. Some markup changes, like: ordered and unordered lists use *, **, ***
instead of tabs (blockquotes will have to be revised too), _bold_, etc.
(I'll have to go through the mail to see what we discussed.)

If we have the new pages (MostLinkedTo, MostEdited etc) then all the
better.


> 
> CREATE TABLE wiki (
> 	pagename VARCHAR(100) NOT NULL,
> 	version INT NOT NULL DEFAULT 1,
> 	flags INT NOT NULL DEFAULT 0,
> 	author VARCHAR(100),
> 	lastmodified INT NOT NULL,
> 	created INT NOT NULL,		# optional
> 	content MEDIUMTEXT NOT NULL,
> 	refs TEXT,			# refs are serialized
> 	PRIMARY KEY (pagename)
> 	);
> 
> CREATE TABLE archive (
> 	pagename VARCHAR(100) NOT NULL,
> 	content MEDIUMTEXT NOT NULL,
> 	refs TEXT,
> 	author VARCHAR(100),		# I guess those two columns
> 	lastmodified INT NOT NULL	# are nice to have
> 	PRIMARY KEY (pagename)
> 	);
> 
> CREATE TABLE wikilinks (
> 	frompage VARCHAR(100) NOT NULL,
> 	topage VARCHAR(100) NOT NULL,
> 	PRIMARY KEY (frompage, topage)
> 	);
> 
> CREATE TABLE hottopics (		# optional table
> 	pagename VARCHAR(100) NOT NULL,
> 	lastmodified INT NOT NULL
> 	PRIMARY KEY (pagename, lastmodified)
> 	);
> 
> CREATE TABLE hitcount (			# optional table
> 	pagename VARCHAR(100) NOT NULL,	# hits are in separate table in
> 	hits INT NOT NULL DEFAULT 0,	# order to avoid locking our
> 	PRIMARY KEY (pagename)		# main wiki table
> 	);
> 
> 

OK, let's consider this the signoff on the new schema. Nicholas suggests,
and I also had considered, allowing "appending" to a page instead of
edting it, which would absolve concurrency problems; so we might want to
add another table (version 1.4, say) where a page's appends go to, and
optionally they can be merged with the main page; but maybe that's overly
optimistic.

> What about categories and paths?

> While I'm still pretty fond of paths I'm not sure about
> categories anymore. The more I think about them, the more I dislike
> them. If people feel they really need them, they can create them
> easily by what is already provided through wiki. Adding a formal

True; in fact, you can do _anything_ in a Wiki if enough people agree to
that social convention. RoadMaps and StartingPoints are good examples of
this; after the pages and discussions mature, a human draws a map showing
people how to navigate it. We can get the machine to extract more meaning
from what's there, but ultimately a Wiki is a social space for humans and
it needs humans to give it meaning.

Categories are not on the list for 1.2, and I need to find out more about
how they are implemented and used anyway.

> I envision wiki more like a cloud, where several paths lead into it
> and the deeper you go, the more misty it becomes, and soon you wander
> off your path following hyperlinks. Sure, it's unstructured, it's
> chaotic. But to that end: use your browsers back button. Or
> alternatively, the wiki could give you a cookie and create a map of
> pages visited on the fly. Better yet, try to come up with a
> search not based on words, but on links (and the pagerank) that
> shows you related or important pages within reach.
> Navigation like this is far more useful than trying to press a highly 
> dynamic site into rigid categories.

Very poetic :-)

> p.s. I'm gone for the weekend - so don't be suprised if I don't
> answer emails until Wednesday.

Have a nice weekend! I'll roll out 1.1.5 if I can.

sw

...............................ooo0000ooo.................................
   Hear FM quality freeform radio through the Internet: http://wcsb.org/
                     home page: www.wcsb.org/~swain