Reinforcement Learning and
Artificial
Intelligence (RLAI)
Suggested
changes to the open page infrastructure
The ambition
of
this web page is to
describe and discuss possible changes to the interface and
software underlying open web pages. This is the place the open
pages magicians list their "to do" lists and other plans for the
future. This is also the place for any and everyone
to
make suggestions about the open page system as a whole. The best
way to make suggestions is to append them to the end of this page using
the extension mechanism, i.e., by clicking the extend link at the
bottom of this page. Be sure to check the "Notify
subscribers" box on the extension form, so that those who might address
your suggestion are automatically notified of it. If your
suggestion, question or comment is about a particular open page, then
it would be better to put it on that page (by extending that page).
Text in orange were
added, for example, to an existing extension. Items in purple are slated for being
removed from this page and added
to the suggestions
archive. Some older versions of this page are here and here.
As of Oct 11, 2004 we have been officially running OpenPages 1.0.
We have also been running OpenPages2, even though it is really best
thought of as a beta, and probably will never be completed. Here
is a sample page
from the new system. It shows promise, but probably cannot
compete with large efforts such as google sites and WYSIWYG wikis and
other open source projects that are sure to follow. And because
of that, we are no longer actively developing either open page system.
A New Proposal for OpenPages 2
see
here. an even newer proposal, based on in-browser editing, is
starting to be formed here.
Proposals for OpenPages 2
OpenPages 2.0 will be based on membership and the complete elimination
of filenames.
It will permit pages to be restricted to subsets of users, separately
for reading, extending, and editing.
It will include a better subscription model, with subscription and
anti-subscription to whole trees
of pages. This will require editors to indicate which linked-to
pages should be considered child pages and which not. In fact, we
should maintain bi-directional child-parent links, but that part can be
automated. It might be best to do this improvement before a full
OpenPages 2, as it does not require membership.`
Suggestions for changes to OpenPages 1
Highest priority:
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.
Let subscribers desubscribe by email without human
administration. Is this really done yet? Does it
work? What about de-subscribing for addresses other than the
account i am replying from (because of email forwarding)? This is done, including the email
forwarding problem.
Making the subscriber list publically viewable (but not machine
sniffable) I think this can
also be declared done.
Problem: the page that you get after "Help"
and "Click here" makes multiple references to /openpageinfrastructure/emailForm.html,
but this page was never made. I put a dummy page there, pointing to
anna. -rich
If fixed the multiple references to the
emailForm page in the troubleshooting section. For now, it is just set
as a mailto:anna@cs.ualberta.ca link.
We were going to make a
page with a form which could be redirected to whoever was in charge of
troubleshooting, but I guess we didn't get to that.
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.
This is a suggestion for something new. New
functionality.
Something our users want is reliability, in particular, permanence.
They want good reason to believe content in an open page will never be
lost. They want the ability to cite an open page in such a way that
they will always get the content of that page as it was at a certain
time rather than as it has been changed to be. Moreover, we would like
this to be done securely so that the content truly cannot be altered or
destroyed, ideally even by system wizards....
Ah, but really, thinking again, this is a functionality separable from
open pages. Useful in open pages, but better to be separated from it.
It has many uses other than open pages and is really a totally
different focus that needs a full attention to it alone. I will send an
email about the "Permanent Data Registry" as an idea for a new business.
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.
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 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).
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.
That's all for now. Formatting the cvs diff in the archive is proving
to be quite challenging.
Email discussions can now be recorded to an
open page. Simply include rlai@cs.ualberta.ca as one of the recipients
as follows:
"page:pagename.html"
Where pagename is the name of the page
(openpageinfrastructure/suggestions.html) for the suggestions page).
You have to put page:in front of the page name for now. That was a
temporary design decision to make sure other emails aren't confused as
openpage email discussions.
If the page does not exist, then it is created, with the subject of the
email used as the title of the page.
There is no parsing of the email done at the moment. The whole body of
the message is taken as a new extension as-is. So, if you have previous
emails in the discussion quoted:
> previous message
current message
Then the quoted part will be included in the new extension, even though
it has already been included in a previous email/extension.
This is just the initial stage. Improvements are on their way.
You can't replace a page you have edited
(that is, you have to close the file you're working on and re-get it in
order to add to your own changes) and Help->Check Here for
publishing error reasons doesn't tell you anything.
I think we may need to generate some kind of
notification, say to a page's designated editor, every time the page is
changed, even trivially, and whether or not the author does an explicit
notify.
This would prevent surrepticious authoring and thus some kinds of
abuse. This would enable editors to track all changes so that she can
decline them or modify them if necessary.
I guess the main problem with this is that currently Open Pages has no
concept of a designated editor. There is a subscriber list, but that is
all. Perhaps
this is a concept that should be implemented? Otherwise this
notification would have to be sent to the whole subscriber list.
Another bug in something important that used
to work: i can't publish and republish the same page. This is essential
to the user experience. He should not hesitate to save and preserve her
work.
Anna, did you do this before by checking the user/source of the last
publish, allowing a technically out-of-date publish if from the same
user?
Rich
Republishing used to be implemented by
checking the IP address of the modifier against the IP address of the
last modification - if they were the same, the change was allowed. I
don't know how the checking works now, so I don't know if this is easy
to implement.
(see my comment a bit higher on the suggestions page) Also, the
Help-> I tried to publish and it failed link does not contain any
useful information anymore. I don't know if there are any error
messages any more.
Can we respond to OpenPage emails?
Ok, now it is possible to republish and
republish the same page.
However, if your version has become out of date then publishing will
still fail. So it should all be working good.
About responding to OpenPage emails:
Currently it is not possible to simply reply to a notification.
However, this is an interesting idea and would be quite easy to
implement.
Regarding the format of the "notify" email:
I
find it hard to immediately read the most important information,
because it's not separated by whitespace. I think the clutter detracts
from the possibility of using open pages as a mailing list replacement.
Mainly, the automatically generated text should be less obtrusive.
For example, here's the current format:
----
A change has been made to /RLAI/labInfo.html,
an open web page to which you are subscribed.
The author of this notification is Anna
The author has summarised the changes as follows:
I just added the software/tools policy to the lab web page. And
subscribed everyone in the lab who wasn't already subscribed.
Remove yourself if you must, but it shouldn't be high traffic.
To
unsubscribe anna@cs.ualberta.ca from this page, reply to this message
with the subject REMOVE (make no changes to the message body).
----
The
"A change has been made to . . . " line is informative, but the page is
now in the subject line, which is great. So I already know the most
important part of the information in the first line, from the subject,
and it's not that important to read it again. Could it go at the bottom?
"The author of this notification is . . . " also not that informative.
The name is.
It's
hard to pick out where the actual text written by the person begins and
the automatically generated text ends. So, I propose something like
this:
From and Subject line of the email itself remain as
they are, or possible from changes to "Anna, via the OpenPages Bot" or
"Anonymous, via the OpenPages Bot" if nothing was entered.
The email itself, using the above message as an example:
------------------------
I just added the software/tools policy to the lab web page. And
subscribed everyone in the lab who wasn't already subscribed.
Remove yourself if you must, but it shouldn't be high traffic. (Note
that this is all the text that the notifier entered)
Anna (the name as entered by the notifier)
---- (some kind of separating line)
A change has been made to /RLAI/labInfo.html,
an open web page to which you are subscribed.
The author of this notification is Anna
To
unsubscribe anna@cs.ualberta.ca from this page, reply to this message
with the subject REMOVE (make no changes to the message body).
----------------------------- (end email)
Or something like that. But the automatically generated text should be
much less intrusive.
You are absolutely right Anna. I have been
meaning to update this form
for some time...and i am still meaning to do it...pretty...soon. -rich
The counter link at the bottom of the page
now displays the number of visitors and the number of subscribers.
Also, the trailing space was removed. -Mark
little problem: Extensions seem to lose any
tabs in the submitted text.
Better way to handle notifications and email
discussion... might be to show an email address for the page. email to
that address goes to the subscribers but is otherwise like ordinary
mail. in particular you know who it is from and can reply to it. Users
can either click on the address shown on the page or cut and paste it
into their email client.
this
will eliminate questions about how to format the email message sent on
notifications. (still an issue on extensions though.)
rich
The extend submission form needs to be
slightly taller (button is half cut off). -r
Priyanka and I thought a bit more
about changing the notification process so that it works thru email.
This is done by giving the page an email address that works like a
mailing list with the page subscribers as the list subscribers. We
thought thru the mechanism for this. The email address cannot be page
specific - it must be to the openPageBot@cs.ualberta.ca (or whatever)
so we have to put all the information identifying the page in the
quoted part of the email address. We are thinking the way to do this is
just to put the url in the quoted part. it will be kinda long, but
clear and relatively easy to remember and even create by hand.
But
we should think -- it this really a good idea to involve email in
sending/changing, or is it better to have all that work thru a browser,
reducing the number of software components involved?
rich
Ok, it is now possible to email all the
subscribers of an openpage. For example, to send a message to the
subscribers of this page you would send to:
Then
all the subscribers would receive a message from you, addressed to the
subscribers. At the bottom of the message is instructions on how to
unsubscribe.
There is now a directory in openpages that
is "semi-private". All files in rlai.cs.ualberta.ca/private are
publically viewable, but only those who know the username and password
can edit or create a page.
How are the username and password set for a
private page?
And, "private" is not quite right, as the pages are publically
viewable. i'm not sure what is right. "controlled"? a bit too negative.
maybe "protected". or "group" because they are editable by a specific
group.
rich
We've got a big bug right now! Extensions
with long lines are not wrapping! Users are getting unreadable
extensions - as in
/RLAI/rewardhypothesis.html. This must be
fixed right away. -rich
alright. Should be working fine
now.
Rich, do you mean in the emails that are
sent to subscribers, or long lines on the actual open page (or both)?
Mark
It feels like it should be easier to reply
to an email notification (like this one) with a note to the author.
Perhaps a reply to field on extensions and notifications?
Also, i have a sneaky idea for pages that are editable by a restricted
group of people. In short, we have an _unlinked page_ (my new name for
an unlisted page - it's a page with no links to it!) and we have an
_alias_ to it, a sort of _dark link_. The alias is the public name. It
is a file in an /alias/ subdirectory that does php or something and
creates the page when asks for by making a copy of the page at the
secret url. Thus anyone can read the page via the alias, but only those
who know the secret (real) filename can edit it (in the normal way).
Thus, no usernames or passwords, just unlinked pages, which we have
already established (and which require no infrastructure other than
documentation).
When you try to create a new page in the alias/ subdir you are instead
asked to provide the secret url.
rich
I would like to add another link to the
bottom of the page. The
link "Email" should pop up a window telling about the email features of
open pages and, most importantly, giving the email address for that
specific page in a convenient form for cutting and pasting into an
email message.
We
should also lose the link "subscribers" by merging it with the final
link which gives info on the current page. We could just list the
subscribers there. This will free up room on the last two lines
for "email".
We could also take the "by the RLAI group" from the last two lines to
free up even more space.
rich
Now that emailing to subscribers is working
without needing the
web-based form, I'm happy, but I think we need an unsubscribe link to
be appended to the message.
-------------------------
Problem: restore on this page:
/RLAI/RLAIcourse/RLAIcourse.html
generates an
"Internal Server Error
The server encountered an internal error or misconfiguration and was
unable to complete your request."
-rich
Restore error has been fixed.
-Mark
Aliased pages now have a different footer
then regular pages. Final tweaking of the new footer is probably
required, however.
Mark
Removed the requirement that alias pages end
with .cgi
Added a header to alias pages that say they are read-only
Was does it mean to subscribe to an alias page?
Mark
Error messages caused by publishing errors
should now be much more likely to work through the "Help' link.
There was a small bug in the viewpublishlog
script, but that has been fixed now. Everything should be working good.
Mark
I am a little concerned the terminology of
"extend", as in "Extend this page" is not very clear and welcoming.
It should be more transparent! Maybe the link needs to be
"Add a note" or "Comment".
rich
The extend and notify forms have been
updated. As well, the emails sent
for extensions and notifications are almost finished (the unsubscribe
part is not quite done).
Don't let notify window be closed without
warning of message lost.
Stats page should include date since along
with page-view counts.
