RLAI Reinforcement Learning and Artificial Intelligence (RLAI)

Suggestions Archive

The ambition of this page is to keep an archive of the suggestions page. The suggestions below have already been taken into account and hence have been removed from the suggestions page.

Back to /openpageinfrastructure/suggestions.html

1. Automatically generated back link on missing pages.
2. Extension notifications to include text of the extension.
3. Displaying list of subscribers to a page.
4. Setting titles for a new page(missing page).
5. Visitor count on pages.
6. Email notifications.
7. Archiving for open pages.

Automatically generated back link on missing pages

>>I think it would be great if new pages that were added had a javascript "back" link built in to them. Or, a hard link back to the main page. Something like that.

Otherwise its hard to find your way back if people don't manually make a link.

Also, while I'm at it - name the main page index.html so the url can be shorter (so we only need to use the folder not the entire path) 

[Rich: No, No, forget about file names!  That way lies the old way of thinking!]
[Anna: Definitely long paths are a problem, though. Magic users can set up .htaccess files to forward appropriately.]
I think we should consider this Done.

>>The missing.shtml should be altered, first to provide a link back to the previous page (from whence the missing page was accessed) as suggested above. The link should appear as

back to /callingpage.html

except in a smaller font and flush right. DONE - not small - where should it go? - check it out nonexistent page
A: that's great. put the link just at the bottom of the ambition statement area, as suggested rewardhypothesis.html. -rich

Second, in the line "The ambition of this web page is to..." remove the word "web". DONE

Third, in the initial mouseover text, instead of "[Anonymous, Jan 1 2004]", put just the current date.  DONE

Good work.  -rich

>>Oops. New/missing pages appear with the automatic back link to the page that called them, but when you actually go to create the page by editing it, the back link disappears. Thus it doesn't work at all at present. 

>>No, back links aren't implemented. The simple way I tried to do it doesn't work (because Mozilla's grabbing of the page for editing is an isolated get request, we can't use the referrering page to construct the back link and have to either use Apache's log file or start setting cookies). So whatever is done for back links, it has to be done from scratch. 

>>I discovered that the error document (missing.shtml) can be a cgi script (missing.py for example) and so I thought I'd be able to do the back link thing that way. cgi scripts have an environment variable HTTP_REFERER that refers to the page that led to the current one. So, that would seem to work, but if you just type a missing page into your browser the HTTP_REFERER variable will be empty. Is this ok? Can we assume that all new pages will have a link to them before they are created? Anna, were you using Javascript when you implemented back links?  

>>Using the HTTP_REFERER variable of a cgi script is exactly the same as using it in an SSL file, because the cgi programs just get the value from apache. No, it isn't going to work. If you click on a link to a missing page, you will see the back link. Then when you hit command-E to edit it, the back link will disappear because when you hit command-E Mozilla makes a totally new get request - exactly equivalent to typing the URL into the browser. So HTTP_REFERER will not be set because you weren't refered to the page.

But there's no reason missing.shtml needs to be an SSL file - a python cgi file is fine. I'm not sure which is the active one, check the httpd.conf file and delete whichever one it doesn't refer to. 

>> If we want to link to the last page accessed by that user, then even if you type in a new URL directly, it will make up a link for you (as opposed to having to make the link then click on it). In that case the best approach is probably to have the missing page program look up in the Apache logs to find out the last file viewed by the user at that IP address - if it can. I think it can look in the logs (we might have permissions problems). That's a bit nicer than a cookie because some people are gun-shy about information being stored on *their* computers, and if they have really tight security settings they'll get warnings on every page, which would be annoying.

>>Ok! Back links are done! All newly created pages automatically have a link to the last page the user viewed on rlai. And when they select Edit Page the link stays. I used the apache logs to search for the last page from that ip address that was not the current page. Let me know if there are any problems with it. 

Extension notification to include text of the extension

>>I think we want to change the notification of extensions to include the text of the extension.
DONE by somebody.  good work.

>>We need a "diff" feature, or something, because I get (or send) a notification that something has changed, and there's no clear way of knowning what all is new. If it's an extension, that's easy to figure out, but if it's comments added in the body, that's hard.

So maybe I shouldn't be adding comments to the body. But without any kind of threading of the discussion, it gets really cluttered really quickly.

Do we expect people to do (via HTML) their own threading? Their own highlighting? 

A: I think it is not unreasonable to ask those who edit the page body, and who want to bring their changes to the attention of subscribers, to include a substantial description of their changes in the notification message.  Remember that message can contain great swaths of the modified text.  And anyway i  can't think of a better way. -rich

Displaying list of subscribers to a page

>>I am thinking we should make the list of subscribers visible to users. This would help in a lot of ways, and can be done in a way that prevents potential downsides.

The benefits are that 1) people can tell if they are already subscribed, 2) people can tell if anyone else has subscribed (and thus might respond to their note), 3) people can tell how much interest there is in their page, and generally 4) there will be some balance between the invisibility of the lurkers viewing and the authors out there with their ideas exposed.

The potential downside is that people's email addresses become visible and might be picked up by machines or harassers. However, this can be dealt with. I suggest just subtly corrupting the addresses, say by changing one letter at random in the username and domain name. That should be enough to stop machines while still serving the other purposes. 

[Anna: Yeeees, one letter would solve the bot problem, but not the people harvesters. What about only showing, say, the first 4 letters of the username and the first 4 letters of the domain name? Or some obscure configuration. And we better warn people about that when they subscribe, or we get in trouble.

Or, we could simply, at the bottom of each page, display the number of people subscribed. We still need a simple "check if I'm subscribed" mechanism, but I think that can be folded into the subscription pop-up. Knowing that there are people subscribed is really important.

For balancing the invisibility of lurkers and the exposure of authors, we could allow the author of a page to view the subscription list.]

A decision was made on this at the October 20 meeting - we will enable the display of subscribers with just their usernames with no domain names, or alternately with a
name provided by the subscriber (could be anonymous).  The subscriber list will appear on clicking a "subscribers" link in the bottom material.

>>I really want to be able to see the subscribers! -rich 

The list is now visible. I have to yet add the option to let people have their names displayed instead of their email logins.

Setting title for a new page(missing page)

>>Newly created pages should automatically set the title to be whatever is the first line enclosed by h1 tags, if it is the default title. 

>> If a new page is created and the title is not set, then it is taken from the first h1 field. There is a problem with this though, because the missing page doesn't use h1 for it's title heading, so you have to explicity switch to using h1.

>>missing.shtml doesn't seem to work properly in Internet Explorer 6.0
under Windows XP. Non-existant pages come up with a generic error "This page cannot be found". Haven't tried Internet Explorer under OS X.

>>That's weird about missing not working in Internet Explorer - the first thing that comes to mind is that IE might not properly respond to the 401 code (or maybe it's the 403 code, and that's why it's not properly responding). The best test would be to see if it displays the custom missing page of *any* site, and if it doesn't, it's a bad program.

>>Ok, so I put the ErrorDocument directive in the .htaccess file and now missing.shtml works! Apparently IE doesn't like it in httpd.conf only... Are there any reasons it shouldn't be in .htaccess? Also, there are 2 versions of missing.shtml: /cgi-bin/missing.shtml and /openpageinfrastructure/missing.shtml. Which is the right one? 

>>No, no reason why it shouldn't be in the .htaccess file. I was moving things into the httpd.conf file because it is faster to not use .htaccess files, but we're going to need them for passwords, so putting other stuff in there doesn't matter.

Visitor count on pages

>>Something about page visit counts would be good. Maybe a bottom link to see the count. To help page maintainers know if they are reaching anybody. -rich 

>>Ok, so the viewcount on every page is up. It's at the bottom right of every page. Also, there's a link to the Archive at the bottom of every page. Overwrite protection is also done. If you start editing a page in Mozilla and someone else changes it in the mean time then you won't be able to publish.

>>The visitor count at the bottom of each page has been changed to just a number which is a link to a page with more information. Currently it's counting visitors, unique visitors, extensions and edits. I imagine in the future it will become more detailed and more explanatory, but the basic idea is there. 

Email notifications

>>The subject line of the email notification should begin with the meaningful part of the file name, e.g., instead of

Change to open web page /openpageinfrastructure/suggestions.html

we should get

openpageinfrastructure/suggestions.html has been changed.

[For OpenPages 2.0, going one step further, we should use in the subject line something more meaningful than file names.  We should use the title/header of the page.]

>>The emails that OpenPages sends should be formatted better. With a proper from and to field. And the subject line has been shortened. Also, these changes in the emails are now in extension notifications AND general notifications (when you click on notify).

That's all for now. Formatting the cvs diff in the archive is proving to be quite challenging. 

Archiving for open pages

>>Archiving - Finished! Anything else needed? Possible additions: a link to the different versions of a page on each page, a way to automatically revert to an old version (maybe not a good idea), a nicer looking diff display. [ Mark Lee, Mon Jan 24 14:28:09 2005]

>>Ok, so basic archiving is up. Openpages is being archived in a CVS repository (Subversion was causing many problems). The archive can be viewed online using ViewCVS (I know it looks kinda ugly right now). The address for that is OpenpagesArchive/viewcvs.cgi/www/

>>It is possible with the archiving that is in place right now to refer to a particular version of a page. (A page as it was at a certain time). For example, to get version 1.15 of this suggestions page use this link: /OpenpagesArchive/viewcvs.cgi/*checkout*/www/openpageinfrastructure/suggestions.html?rev=1.15. Or, just to get a list of versions for a page use /OpenpagesArchive/viewcvs.cgi/*checkout*/www/openpageinfrastructure/suggestions.html

I don't think it's possible to create some kind of archive that is truly impossible to destroy. Pretty much if it can be created then it can be destroyed. But, we can make it so that only administrators have that potential, and so as long as they do things correctly the archive should be stable. 

>>I changed the diff functionality in the Openpages Archive to make it more user friendly. Now it shows the differences in the formatted page, rather than in the html source code. A good example of how this looks is at  /OpenpagesArchive/viewcvs.cgi/www/openpageinfrastructure/suggestions.html.diff?r1=1.16&r2=1.17

Extend this Page   How to edit   Style   Subscribe   Notify   Suggest   Help   This open web page hosted at the University of Alberta.   Terms of use  2666/0