I think this was Jeff's goal as well, but I don't know if he realized it
(Jeff?). I think we'd all like to see rendering modularized, so go ahead
with it, but don't bother forking the code base.
I've just finished Jakob Nielsen's "Designing Web Usability" and have some
ideas about the page layout, and as time permits I'll be checking in those
changes this week (at work, we are now in the "death march" to reach a
deadline, so time is precious).
I want to shrink the logo, add a nav bar across the top and maybe the
bottom too (to reduce the amount of scrolling needed), and add Ari's Wiki
feature of how many times a page was edited (not necessary but I like it).
Arno drafted the "wikilinks" table which hasn't been implemented yet, but
I want to add a right-hand rail listing all the pages that link to the
current one. I got this idea from Nielsen's book; having "related pages"
in a right hand rail is a Web convention apparently, and I have long been
bothered by how this feature is hidden away in the page title link (i.e.
click the page title 'FrontPage' and see all the pages that link to
FrontPage).
Ideally it should be configurable; if the Wiki admin doesn't want the
performance penalty of listing all related pages (a mere SELECT statement
though it is) or the page clutter of a list of titles, they can leave it
out.
I think the nav bar I drafted last night was:
EditText | Changes | PageInfo | Help | MostPopular | RecentChanges |
FindPage
and it will just be a set of plain text links, to satisfy Lynx and Emacs
w3 mode (which I test PhpWiki in periodically. There could also be a
WhatLinksToThisPage link of some kind rather than list the pages on the
right side. Users can add an imagemap if they want.
A long term goal I have is to revamp FindPage entirely... there are many
things a search can do that are totally feasible in PhpWiki, like all
pages returned by the search have the search term highlighted when the
user clicks on them.
sw
On Tue, 29 Aug 2000, Aredridel Niothke wrote:
> Jeff's OO work aside, I was wondering if it would be appropriate to make
> the rendering engine modular? I've taken this approach to some extent on the
> Wiki I've been hacking on, and I was thinking it would be rather nice to be
> able to change which wiki markup language is used on a wiki upon unpacking the
> tarball: Specifically, one could have an HTML parser, so HTML could be used
> safely, or a "standard PHPWiki" language, or the language I've used on the
> NBTSWikiWiki (http://www.nbtsc.org/wiki), which has the goal of being almost
> as readable unrendered as in HTML.
>
> It's quite possible to modularize the renderer and let the user simply
> uncomment a few include lines in their wiki_config.php3 to select the wiki
> language.
>
> Does anyone have any objection to my checking in such changes? Should I
> branch the code?
>
> Aredridel
> _______________________________________________
> Phpwiki-talk mailing list
> Php...@li...
> http://lists.sourceforge.net/mailman/listinfo/phpwiki-talk
>
...............................ooo0000ooo.................................
Hear FM quality freeform radio through the Internet: http://wcsb.org/
home page: www.wcsb.org/~swain
|
